|Subject:||Re: Turn around time|
|Posted by:||Remy Lebeau (TeamB) (email@example.com)|
|Date:||Tue, 11 Jul 2006|
"Malcolm Smith" <m.smi…@comvision.net.au> wrote in message
> When the client is on the same machine, the time it takes to send an
> entire frame of data (plus overhead associated with my protocol)
> takes approx 1ms (between 0 and 2).
> A remote connection on a 100base network takes anywhere from
> 50 to 200ms per frame. Is this degree of difference to be expected.
Yes. There is a lot more overhead involved to send data out over the actual
network then to transmit it only on the local machine.
> In order to get real time we need less than 40ms.
You should consider using UDP instead of TCP for streaming media. UDP is a
lot faster, although much less reliable than TCP. But a lot of systems used
online today, such as RealMedia, Skype, VoIP, etc tend to use UDP. The
integrity of individual audio/video frames is not very important in the
larger scheme of things. A few dropped audio packets here and there is not
very noticable to humans, and video is best handled by sending differences
between packets instead of sending whole pictures every time. The
differences can be overlayed on top of each time to make up complete
pictures on the receiving end, and then just send a resync picture every so
often in case frames were dropped. A lot of video formats use differential
frames anyway to reduce data size.
> In the past I tried OpenWriteBuffer(), FlushWriteBuffer() etc
That will actually slow the code down, not speed it up, because then you are
invoking the extra overhead of buffering the data into memory before sending
it. You you are making a second copy of your data, and then Indy has to
wait for the copy to be sent in full. Sending the original data directly
without buffering it first is faster.
> the results were worse than using the Write() based functions and
> letting Indy determine when to send the data.
It is not Indy who is deciding when to send the data. It is the network
subsystem itself. Indy just puts data into the socket's internal buffers,
and then sockets send the data at their leisure after control has returned
One thing you might consider doing is disabling the Nagle algorithm on the
socket. When enabled, a socket will buffer outbound packets and then send
the buffer when the sending is more efficient. Disabling the algorithm
causes the socket to send smaller packets more often without as much
Turn around time posted by Malcolm Smith on Tue, 11 Jul 2006