End to End compression?

Tim · Fri Jul 22, 2005 6:36 pm

Does the iSCSI standard allow for end-to-end compresson to speed up network transfer speeds?

If so, can this be implemented into StarWind/StorPort via plugin or otherwise?

I'm not concerned about the CPU usage, the speed of access to remote devices is more important to me.

Fri Jul 22, 2005 9:20 pm

No compression allowed by standard. Only encryption using IPsec (supported).

Uppdate your network hardware with iSCSI offload capable one. Or get 10 GbE adapters. That's all we can do now...

Tim wrote:Does the iSCSI standard allow for end-to-end compresson to speed up network transfer speeds?

If so, can this be implemented into StarWind/StorPort via plugin or otherwise?

I'm not concerned about the CPU usage, the speed of access to remote devices is more important to me.

Tim · Fri Jul 22, 2005 11:39 pm

Uppdate your network hardware with iSCSI offload capable one.

No chance

Have you seen the prices?

Thanks for your time

Fri Jul 22, 2005 11:41 pm

I don't know whom you represent. Are you individual or some OEM representative.

Tim wrote:
Uppdate your network hardware with iSCSI offload capable one.
No chance Have you seen the prices?

Thanks for your time

Tim · Fri Jul 22, 2005 11:49 pm

I don't know whom you represent. Are you individual or some OEM representative.

Just a private home user with an interest in networking technology.

I have a little network of machines with 3COM 3C1000 Gigabit adapters connected by a NetGear GS108 Gigabit switch.

VOIP phone soon to be plugged into my router...

Sat Jul 23, 2005 2:43 pm

Unfortunately we cannot do any specification violating expensions.

Tim wrote:
I don't know whom you represent. Are you individual or some OEM representative.
Just a private home user with an interest in networking technology.

I have a little network of machines with 3COM 3C1000 Gigabit adapters connected by a NetGear GS108 Gigabit switch.

VOIP phone soon to be plugged into my router...

Tim · Sat Jul 23, 2005 3:49 pm

Unfortunately we cannot do any specification violating extensions.

Yes of course, I wouldn't expect you to do that

It was just a thought

Sat Jul 23, 2005 8:06 pm

RDS would release some new networking storage protocol support soon. It would not be iSCSI, something different. In in (as we'll be maintaining it) we'll offer encryption and compression to increase traffic. At least would try to do so

Tim wrote:
Unfortunately we cannot do any specification violating extensions.
Yes of course, I wouldn't expect you to do that

It was just a thought

Tim · Sun Jul 24, 2005 12:07 am

RDS would release some new networking storage protocol support soon. It would not be iSCSI, something different. In in (as we'll be maintaining it) we'll offer encryption and compression to increase traffic. At least would try to do so

Sounds interesting. I'll keep a look out for that.

Sun Jul 24, 2005 12:20 pm

We have your e-mail so would keep you updated.

Tim wrote:
RDS would release some new networking storage protocol support soon. It would not be iSCSI, something different. In in (as we'll be maintaining it) we'll offer encryption and compression to increase traffic. At least would try to do so
Sounds interesting. I'll keep a look out for that.

Tim · Thu Oct 13, 2005 8:13 am

Remember this?

Any news?

Thu Oct 13, 2005 2:03 pm

Yes. Please drop me a message to anton@rocketdivision.com and we'll provide you with some interesting stuff to test.

Tim wrote:Remember this?

Any news?

DJ_Datte · Sat Dec 31, 2005 3:34 pm

I am interested in looking at this technology too, Anton! I've sent you a
email to that address!

/Damir

Tue Jan 03, 2006 1:23 pm

I've answered two or three e-mails about compression in real time and iSCSI cache. Would duplicate the answer there for other people:

1) According to our experiments compression makes sense only on very low connection speeds (kilobits and not even megabits) and could be successfully utilized only for WAN. Even 100 megabit traffic cannot be compressed in real-time with modern CPUs. Instead of making things faster such a "improvement" inserts delays. And TCP does not work well with "pulsating" traffic model - pipeline should be always feeled to have maximum possible thrououtput. For GbE things get even WORSER. So this idea was dropped.

2) iSCSI cache also does not work with GbE which is seems to become a standard for storage wiring these days. No single local hard disk can have sustained transfer rate at 100-150 MB/sec (GbE storage traffic with StarWind for example). So this one is delayed for unreasonable time.

3) If you're looking for AoE (ATA-over-Ethernet) stack implementation for Windows - we're done with client side of it. So if you're lucky to have one of the CoRAID blades or use Linux AoE target - you can ask for modified version of StarPort with built-in AoE support. This one is done and we'll investigate a lot of time and money into this techonogy.

Thanks!

DJ_Datte wrote:I am interested in looking at this technology too, Anton! I've sent you a
email to that address!

/Damir

DJ_Datte · Thu Jan 12, 2006 12:02 pm

Hey !

Actually, for my planned uses, and with my testing, a cache (say about 512MB used of a 1GB windows machine) would huge difference. I will need to store huge amounts of data on the iSCSI, but the stuff that is read in one session is allways very localized, or there are very many clients reading from the exact same file .... So a ram cache would be appriciated greatly, for read operations .. I understand both the security risks, and usually very small attractivness of write catche in thease scenarios...

/Damir