| Author |
Message |
Jason Ozolins
Guest
|
 Posted:
Wed Jan 12, 2005 4:47 am Post subject:
Re: Firewire for remote DMA? |
|
|
Paul Rubin wrote:
| Quote: | Characteristic of IP and Ethernet is that both are unreliable
protocols (they are allowed to drop packets) so TCP is needed to put
an acknowledge/retry layer over IP. One improvement (I'm not a TCP
expert though, so maybe it already can work like this) could be to put
the TCP acknowledgement and the application level response into the
same packet. That would get rid of the separate response packet, and
as well, the response packet would itself not need to be acked (there
would be a retry request if it didn't arrive).
|
Try Googling for "delayed ACK". :-)
-Jason |
|
| Back to top |
|
 |
Terje Mathisen
Guest
|
| Posted:
Wed Jan 12, 2005 7:56 am Post subject:
Re: Firewire for remote DMA? |
|
|
Stephen Fuld wrote:
| Quote: | "Patrick Geoffray" <patrick@myri.com> wrote in message
You can achieve decent latency by talking directly to the hardware, but
then the Ethernet switching latency becomes much more important, and there
is no real way to avoid it. According to my Ethernet expert, The spanning
tree part of the Ethernet spec pretty much requires store-and-forward in
the switch.
Isn't "most" of the overhead in the TCP part of TCP/IP and thus could one
develop a replacement for TCP that was slimmed down to the needs of the
particular application and save a lot of overhead, yet still use standard
Ethernet switches?
|
The easy solution would be to use Xerox' original XNS (?) or the Novell
version IPX:
Pretty much raw Ethernet packets, with just a tiny header (to allow
routing), but that would not be needed here, right?
Terje
--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching" |
|
| Back to top |
|
|
Phillip Fayers
Guest
|
| Posted:
Wed Jan 12, 2005 5:12 pm Post subject:
Re: Firewire for remote DMA? |
|
|
Del Cecchi wrote:
| Quote: | It is sort of scary when a circuit designer like me talks about
software. I probably get all sorts of stuff wrong.
|
I'm sure that there are a whole load of people on this newsgroup
who are less qualified than you, like me for instance.
| Quote: | What I meant was
that since, as several long threads in the past have shown, there is a
lot of code between the application and the bare metal of the Ethernet
card that perhaps could be reduced in complexity for the specific
application you are interested in. And this reduction might accomplish
a reduction in latency for your specific application.
|
My guess is that the reason there is a fair bit of latency in various
parts of the machine -> machine packet path is that, well, it wasn't
that important to deal with it. People have been concentrating on
throughput on the network for sometime. Every now and then someone
spots a new application and they go back and redesign.
One example I can think of is the SunOS TCP/IP stack. I started using
Suns back in the SPARCstation 1 days and one of those machine could
saturate a 10Mb/s network without too much trouble. Then someone went
and invented the web and suddenly you couldn't saturate the bandwidth
because you couldn't handle the required number of connections. The
set up/tear down time of network connections was too slow. So the
engineers pulled the software stack apart and eliminated the bottle
necks. If I remember right the Sun stack used to do 3 data copies
for each packet (user to kernel, another to checksum, another to copy
to the device) which the engineers hacked down to 1.
People are now applying the same effort to low latency ethernet,
with various solutions getting the machine to machine latency down
from >40us to <10us. Not quite in the <4us latency of dedicated
high performance connects but pretty close.
--
Phillip Fayers School of Psychology, Cardiff University
Fayers@cf.ac.uk http://www.astro.cf.ac.uk/pub/Phillip.Fayers/
Tel: +44 (0)29 2087 9337 Attribute these comments to me not UWC. |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in