Date: Tue, 31 Mar 1998 15:54:48 +0200 (MET DST) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: rminnich@Sarnoff.COM (Ron G. Minnich) Cc: fenyo@email.enst.fr, freebsd-hackers@FreeBSD.ORG Subject: Re: Virtual Interface Architecture Message-ID: <199803311354.PAA22544@labinfo.iet.unipi.it> In-Reply-To: <Pine.SUN.3.91.980331090833.8941D-100000@terra> from "Ron G. Minnich" at Mar 31, 98 09:13:36 am
next in thread | previous in thread | raw e-mail | index | archive | help
> On 31 Mar 1998, Alex Fenyo wrote: > > "Ron G. Minnich" <rminnich@Sarnoff.COM> writes: > > > btw, a question for hackers: how hard would it be to get 10 microseconds > > > latency on the tcp stack as it stands? Yes, i know: "impossible". how > > > impossible? > > N.B.: I want tcp/ip. And i want the 10 microseconds. How do I get there? > I'm not pretending to be reasonable. But 10 microseconds is 5K > instructions at 500 Mhz, which is where we're going to be this summer. pinging through the loopback interface is now around 100 microseconds, round trip, on a 1yr-old P6-200 with perhaps 60ns DRAM . So i suspect we are not too far from it. 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...) ? I know ping uses ICMP and not TCP (but the latter should be more optimized, although it goes through the socket layer). > Now i have to get through tcp/ip. Any votes on whether I can get through > in 4K instructions? Whatever happened to the infamous 30-instruction tcp > inner loop? on the send side i think it can be reasonably fast. On the receive side the only, minor, difficulty could be having to demux the incoming packet and find the right PCB -- but nothing so hard or time consuming. > > of active messages. People want sockets, not TCP/IP, I think... > > No, not in my neck of the woods. People want what tcp/ip does, they just > want it to be faster. And it should be. 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. Those are all good motivations for using sockets on a different transport if you have special needs for speed. After all porting simple programs from TCP to AF_UNIX sockets it's just a matter of a couple of lines of code, and if you build sockets on a different, very fast, protocol you should have very little trouble. 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?199803311354.PAA22544>