Date: Tue, 31 Mar 1998 18:23:14 +0200 (MET DST) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: rminnich@Sarnoff.COM (Ron G. Minnich) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Virtual Interface Architecture Message-ID: <199803311623.SAA22942@labinfo.iet.unipi.it> In-Reply-To: <Pine.SUN.3.91.980331103920.9500A-100000@terra> from "Ron G. Minnich" at Mar 31, 98 10:58:40 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Are you looking at 10us one-way > > on a single machine, or on a cluster, going through the net (in > > which case you also have the startup costs of the net interface, > > with its few microsecond's inter-frame gap on ethernet...) ? > > The challenge number I put to the extreme linux conference was this: > "from user-mode system call instruction to first bit on the wire, 10 > microseconds". so in this case we are not too far away even just now. I know for sure that a ping across a 100mbit net with P5-100 is around 200us round trip, so it's surely less than 100us one way to the wire with no special optimization. > Why this? Well, UNET does it now, albeit in a somewhat ugly way. It would > be far better to do it via TCP. pardon the ignorance, but what is UNET ? > > I assume you want the reliability that TCP gives you, but depending on > > the underlying network you might not need to implement it in the protocol > > stack. Probably you also want message boundaries to be preserved, > > something that TCP does not guarantee. And if you want to send > > different messages to different receivers, you would not like to pay > > the price of opening/closing a connection each time. > > The problem is that if you do 'something other than tcp', you find in > many cases that people recreate things like: > sequence numbers > retransmit this is why i mention reliability as a desirable thing (and you don't see sequence numbers and retransmits at the application level) and some others which might be undesiderable (as getting arbitrary fragmentation of messages). There is some overhead in TCP that could just be eliminated if you wouldn't have to worry about say cong.control etc -- in other words, some optimizations to the TCP code are certainly possible, but i suspect some significant improvement would also come out from removing useless (for the specific purpose) functions. > In fact, on the RP3, people who worked on that project told me that they > added lost-packet checking in the software. This on an MP interconnect. if this is just a safety check on each read/write (driving to a possibly complex recovery routine that almost never runs) then this is not much a problem for performance. > anyway, the relation of this to -hackers is that it would be neat to see > freebsd get to the challenge number soon. cheers luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803311623.SAA22942>