[Vortex] PATCH: Send messages in 1kbyte frames

Francis Brosnan Blazquez francis at aspl.es
Mon May 5 19:28:45 CEST 2008


Hi Jens,

Some changes have been introduced into the vortex engine to allow
maximizing connection bandwidth.

I've also applied your patch partially [1] to include the new function
to configure the channel receiving window size
(vortex_channel_set_window_size). With changes introduced it is now
possible to get vortex to consume all bandwidth available; see next..

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

<footnote>(Re)reading this I want to note this makes no sense. I meant
to say it is not *only* part of the solution ;-)</footnote>

> 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). 

Maybe this is because the average content sent is smaller than advised
window size or something similar. In any case it is not the final
solution.

The issue was caused by a stop-start cycle defined by sending all
content up to consuming remote channel window, and keep stopped until
next SEQ is received. 

Now two parameters help to control how send operations are performed.
First, the channel window, which will work as it does the TCP window,
that is, the maximum amount of content to be sent until next SEQ frame
is received. The second parameter will be the step or the amount of
content to be sent in the next frame. 

The idea is to avoid consuming all channel window size available on each
send performed, in a way we can reach the "continuous transfer" state,
maximizing all bandwidth available. 

Running test_02h test against a remote host behind a DSL line with
55Kbytes/seconds (roughly) shows data attached (bandwidth_data.log)

First test runs with a channel window size configuration with 4k and a
frame step of 4k. This matches your results showing an inefficient
bandwidth utilization of 22.7 KBytes/segs (around a half).

All next tests are run with a step of 4k (which is the default
implementation) but changing the window size, reaching the continuos
transfer state in some of them.

Second log attached (bandwitdh_data_lan.log) shows the same tests run
against a local lan server. It is interesting to note the best transfer
rate is reached using 4k as frame step and 16k for window size.

In general, using default step value of 4k is a good choice. For the
window size, it is recommended to use 16k or 32k, specially on high
latency connections. This only requires to use
vortex_channel_set_window_size.

However, if it is required to change the frame step, the following set
of functions could be used (not defining them will cause to use default
value of 4k), each one overrides previous. 

- vortex_connection_set_default_next_frame_size_handler
- vortex_connection_set_next_frame_size_handler
- vortex_channel_set_next_frame_size_handler

Cheers!
[1] http://lists.aspl.es/pipermail/vortex/2008-April/000523.html

-- 
Francis Brosnan Blazquez <francis at aspl.es>
Advanced Software Production Line, S.L.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bandwidth_data.log
Type: text/x-log
Size: 1834 bytes
Desc: not available
Url : http://lists.aspl.es/pipermail/vortex/attachments/20080505/8fc72c56/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bandwidth_data_lan.log
Type: text/x-log
Size: 1840 bytes
Desc: not available
Url : http://lists.aspl.es/pipermail/vortex/attachments/20080505/8fc72c56/attachment-0001.bin 


More information about the Vortex mailing list