Software vs Hardware
|
Prev: First Next-Gen CELL Processor: 2 PPEs - 32 SPEs - at least 1 Teraflop
Next: old microcode listings
From: Nick Maclaren on 14 Dec 2006 13:49 In article <els4he$g1v$1(a)trsvr.tr.unisys.com>, timcaffrey(a)aol.com (Tim McCaffrey) writes: |> |> It is relatively easy to design and test a fast integer unit, same |> for cache. Do you know how hard it is to get a TCP/IP |> implementation that interoperates with the rest of the world? |> There is no standard spec, just a bunch of RFCs. If you follow all |> of them, the result probably will not work, much less interoperate. Which I call "Requests For Cursing". A related story may amuse you. When I was working on data transfer from MVS to Unix/MS-DOS/MacOS, I wrote a tar program for MVS from the 'specification' (tar(4)), and it didn't work. So I did what I was expecting to have to do, created a few relevant tar files on every Unix system I had access to and unpicked their contents. They all used different formats and not all would interoperate, of course :-) There were no fewer than FOUR bugs in tar(4) that had been there as far back as I could track, two of which meant that a program written according to it could not interoperate with a real tar program. All four were present in every version of tar(4) that I could find, both Berkeley and System V based. POSIX forced this mess to be sorted out, and it is now a problem of the past. Similarly, any program that implements the RFC for FTP will cause havoc to any real FTP client - in addition to there being two, incompatible binary formats (one used only on old MacOS, as far as I know), it allows file names including any of the 128 7-bit ASCII characters except for CR and LF. Yes, NUL, ESC and SUB are allowed in FTP filenames :-) |> BTW, a few of those TCP/IP experts Nick mentioned work down the |> hall from me, so don't give up hope Nick. Hmm. If I get decent evidence on the generic bug I am trying to trap, I may contact you. Your colleagues may be interested. Regards, Nick Maclaren.
From: Terje Mathisen on 14 Dec 2006 16:04 Tim McCaffrey wrote: > It is relatively easy to design and test a fast integer unit, same > for cache. Do you know how hard it is to get a TCP/IP > implementation that interoperates with the rest of the world? > There is no standard spec, just a bunch of RFCs. If you follow all > of them, the result probably will not work, much less interoperate. Indeed. I have seen a few burn marks from the friction between independent implementations: It used to be that with AIX on one end and Windows on the other, i.e. a very common situation, you could (depending upon average request size and ping time) get Nagle style 200 ms delays between every pair of packets in either or both directions. It didn't even help to manually turn on the TCP_NODELAY (exact spelling?) flag, because Microsoft in their infinite wisdom had decided they knew better, and simply disregarded that flag if set. :-( The result did "work", it just took 2-3 orders of magnitude more time than really needed. Terje -- - <Terje.Mathisen(a)hda.hydro.com> "almost all programming can be viewed as an exercise in caching"
From: Jan Vorbrüggen on 15 Dec 2006 04:24 > HardOCP with their kooky "blind" testing is going to become > an equivalent of "Sterophile" from the sound reproduction field. Blind testing is the only way to exclude perceptual effects due to prior knowledge. As such, it is an established technique, and I wouldn't trust any measurement that relies on an assessment - be that quantitative or qualitative - by a human being that _doesn't_ use it. Given that, using blinding is the correct thing to do here. Whether the particular benchmark in question did the blinding correctly, or is interpreting the results so obtained correctly, is of course another matter. Jan
From: Jan Vorbrüggen on 15 Dec 2006 04:28 > It didn't even help to manually turn on the TCP_NODELAY (exact > spelling?) flag, because Microsoft in their infinite wisdom had decided > they knew better, and simply disregarded that flag if set. :-( The spelling is correct, and I believe that in this particular case, Microsoft have in the mean time seen the light and no longer disregard the setting. There are too many cases where without it, the application is functionally broken because latency is too high. Isn't also the 200 ms a really constant parameter that isn't subject to negotiation between the partners? I wonder whether the designers ever heard of the concept of scaling... Jan
From: Nick Maclaren on 15 Dec 2006 15:03
In article <krq854-t9i.ln1(a)osl016lin.hda.hydro.com>, Terje Mathisen <terje.mathisen(a)hda.hydro.com> writes: |> |> Indeed. I have seen a few burn marks from the friction between |> independent implementations: |> |> It used to be that with AIX on one end and Windows on the other, i.e. a |> very common situation, you could (depending upon average request size |> and ping time) get Nagle style 200 ms delays between every pair of |> packets in either or both directions. |> |> It didn't even help to manually turn on the TCP_NODELAY (exact |> spelling?) flag, because Microsoft in their infinite wisdom had decided |> they knew better, and simply disregarded that flag if set. :-( |> |> The result did "work", it just took 2-3 orders of magnitude more time |> than really needed. One of the two directions between SunOS and HP-UX was like that: one had a low-latency stack and used very small windows; the other relied on large windows for performance. Regards, Nick Maclaren. |