[Vortex] PATCH: Send messages in 1kbyte frames

Jens Alfke jens at mooseyard.com
Thu Apr 24 17:11:25 CEST 2008


On 24 Apr '08, at 4:16 AM, Francis Brosnan Blazquez wrote:

> Right. Updating the window size is not part of the solution IMHO.

I'm finding that in high-latency low-bandwidth connections, increasing  
the window size to 16k helps performance (even with my 1k frame size  
patch).

> With the patch included, a new regression test I'm working on to  
> ensure
> performance in all scenarios, shows poor performance [1] under no  
> delay
> environments (for example a local area network). However, without the
> patch applied [2] better results are found.

Hm, that's too bad. I can see that if there's near-zero latency, the  
performance could be affected by the extra size occupied by the larger  
number of frame headers, and perhaps by the CPU overhead of generating  
and reassembling the frames. Have you done any CPU profiling to see  
whether the latter is an issue?

Does your testing include simulations of slow connections? The typical  
environment for my app is going to be between two consumer DSL or  
cable links (P2P), where the data rate is likely to be 384kbps or  
under, and round-trip delay times may be 200ms or more.

I've been using dummynet with ipfw to simulate such an environment  
across two computers on a LAN, and it works great. Here's how I turn  
it on (as root):

# ipfw add pipe 1 ip from any to any out
#ipfw add pipe 2 ip from any to any in
# ipfw pipe 1 config bw 256kbit/s queue 10 delay 100ms
# ipfw pipe 2 config bw 768kbit/s queue 30 delay 100ms

To turn it off, enter "ipfw flush".

> In general, the change required to fix the issue you have found  
> (vortex
> performance under delay environments) must be dynamic and react  
> properly
> under delay and no delay conditions.

Adjusting this automatically and dynamically might be quite difficult;  
I have no idea how to do it. Perhaps other BEEP implementations have  
figured out how?

In the absence of that, perhaps there could be a "maximum frame size"  
parameter that the client could adjust? To preserve current default  
behavior, it would initially be set to 4k.

—Jens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.aspl.es/pipermail/vortex/attachments/20080424/d461df0e/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1875 bytes
Desc: not available
Url : http://lists.aspl.es/pipermail/vortex/attachments/20080424/d461df0e/attachment.bin 


More information about the Vortex mailing list