[OpenAFS-devel] .35 sec rx delay bug?
Ken Hornstein
kenh@cmf.nrl.navy.mil
Fri, 10 Nov 2006 13:58:32 -0500
>Isn't the TCP checksumming enough? Anyhow, encryption would also have
>this effect.
This is part of the security stuff, not just about data integrity. Right
now Rx data is protected by a weak keyed checksum. Currently RxTCP does
not implement that; I am thinking about doing it. This might complicate
the code more (two code paths). I can't see any way of getting reasonable
transfer rates when doing security on the bulk data, but checksumming
would be less intensive then encryption.
>In any case, I was just curious about it being possible at all. Modern
>servers shouldn't have any problems delivering gige-speed without
>sendfile given sane code, it will be very interesting to see what
>happens when 10gige gets common though. A wild guess is that we'll be
>limited by disk speed.
I can only say that a number of years ago, I was able to saturate
an OC-12 between two machines (real data, being transferred to disk
on each end) with a slightly modified ftp client and server. It
had two features: increased TCP window size, and it used an
Irix-specific mechanism to bypass the buffer cache. If we have the
disk speed available, I can't see a reason why we can't do the same
thing on modern hardware and disks.
--Ken