Return to BSD News archive
#! rnews 5282 bsd Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!spool.mu.edu!howland.reston.ans.net!newsfeed.internetmci.com!zdc!szdc!szdc-e!news From: "John S. Dyson" <toor@dyson.iquest.net> Newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc Subject: Re: TCP latency Date: Tue, 16 Jul 1996 09:44:44 -0500 Organization: John S. Dyson's home machine Lines: 89 Message-ID: <31EBAADC.41C67EA6@dyson.iquest.net> References: <31E6B8AB.3E6C@indy.celebration.net> <4s7j2r$blf@fido.asd.sgi.com> <31E7BD6F.167EB0E7@dyson.iquest.net> <4sfjm8$a04@news.swan.ac.uk> NNTP-Posting-Host: dyson.iquest.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0b5aGold (X11; I; FreeBSD 2.2-CURRENT i386) Xref: euryale.cc.adfa.oz.au comp.os.linux.networking:45436 comp.unix.bsd.netbsd.misc:4076 comp.unix.bsd.freebsd.misc:23752 Alan Cox wrote: > > In article <31E7BD6F.167EB0E7@dyson.iquest.net> "John S. Dyson" <toor@dyson.iquest.net> writes: > >emotional in the support of Linux. Yes, Linus should be happy that > >Linux APPEARS to be catching up in certain areas. That is ALL that can be > >concluded at this point. > > Appears to be catching up. Is that the closest Mr Dyson can get to > admitting he might be losing on something. > This is the attitude that I find extremely distateful. Sorry, but I am not seeing that anyone is loosing here. I have been asking for integrity assocated with claims. If you think that my demanding benchmark results to back up claims is an indication of bad sportmanship, it is my position that unfounded claims are such an indicator. Bottom line, people like you are the ones taking my skepticism personally :-(. > > Yep, Linus got up to three(3) connections :-). Psst, try 1000-3000 > >connections with different IP/PORT addresses, then it all starts getting > >very very interesting :-). > > That is one I'd like to try, and I'd be interested in the figures for both > on the same hardware for each node you are testing against. (DONT do a dumb > two host many connection test its got no value as the packet patterns will not > resemble real traffic and you won't be accurately assessing issues like > L2 cache footprint of arp table lookups. You need to model a real network > with say 300-500 hosts off mixed subnets and on mixed traffic timers to > generate useful stats for say WWW network performance. > We found in our real world tests, that "interesting suprises" have appeared. Too bad we don't have the ability to test Linux, I was kind of hoping that the Linux developers would, and I am still looking for results... > > >competency in benchmarking. I'll bet you that there are qualities about > >me that blow YOU AND LINUS away, but that does not make me better in the > > Apparent ego size ;) > Yep, I don't claim to be expert in everything, like some do. You also do not know me, and I dare say that you would be impressed with how unassuming I am. I claim that my ego is probably even less important to me that yours is to you. It is your ego that is feeling threatened by the technical superiority of FreeBSD :-). Are you in catch-up mode still? > >areas that I am not expert. Additionally, have you been open about > >the attempted recruitment of me onto Linux? (Y'know the VM system needs > >work?) > > Well the last time I looked the VM works rather nicely now, it certainly > seems to work rather well (unlike 1.2). It also passes the portability test > in running on machines with 32 and 64bit architectures, as well as both > physical and various virtual caches, while I'm dubious the FreeBSD vm subsystem > will actually run well on a 64bit architecture - perhaps the NetBSD folk can > answer why they use the Mach VM layer not yours ? > We haven't ported it yet. Our VM system works with >32bit objects on a 32bit arch (we had to do that to support large files.) The question is how well do the VM systems do on architectures that they have been ported to. I dare say that there are slow 64Bit VM systems :-). Most all VM systems work well under light loading conditions, my goal was not to make the VM code "a fair weather friend." The algorithms are scalable to both 64Bits (which again, much of the code is already 64Bit in FreeBSD), and to machines without Modify/Reference bits. I feel that it is a better investment to work on the X86 right now, simply put. Also, we already incur significant 64Bit overhead in our code. The only thing that is needed is the pmap layer for a given machine, and two or three strategically placed ifdefs. If you are interested, I can produce patches to turn off the M/R bits on X86 and minor changes to the upper level system to check it out. I would do so ONLY if you are really interested, which I doubt. By what expertise can you say that you are dubious about it, have you studied it, or even benchmarked it (carefully) with loading benchmarks? Do you have any valid complaints about the FreeBSD VM system or any claims about the VM system made herein? Additionally, I did not even bring up the FreeBSD system -- Larry brought up Linux's VM system -- your questions are bait, not germaine and frankly sound like sour grapes. John