jk3264

@mudmanc4: Ah, that is clear now. Thanks. Netbios has been off for a rather long time -- years at least. And it wouldn't have even occurred to me to try to use this sort of tool to sort out QOS problems (perhaps just lack of imagination ). But now I at least understand your comment. Much appreciated.

The exchanges with CA3LE focused on the problem I was concerned about, but just to clarify... I didn't say "simultaneously". The procedure I was using was to try to run an automatic (repeated) test on one machine that wasn't doing anything else. When I saw a test completed with a very slow download rate (note that we are talking about a couple of orders of magnitude here), I manually reran the test from another machine (different loading, different hardware, different configuration, even in some cases different operating system) as an informal means of verifying that the lousy results were not simply an artifact of a transient on the test machine. The problem I was seeing (see the rest of the thread) was the the "express" feature was overriding even the specific size tests. Ask for a megabyte; get a complaint about not being able to run tests below 97 (?) KBps. Not sure I understand this. When I said "packet analyzer" I meant a dedicated device that was actually sniffing packets on the LAN. And the only reason for doing that (and for making measurements on the router) was to be sure that some odd device on the LAN wasn't creating a packet flood and swamping the connection. Given that the internal LAN is running with gig Ethernet switches, it is not obvious what netbios on a client machine could possibly tell me that would be relevant. When I see an odd pattern in a WAN measurement, my first instinct is to try to verify that it isn't actually being caused by something going on with local machines (hence repeating the test on a second machine) or otherwise on the LAN.

Thanks very much. And "not messing around" is greatly appreciated. For amusement (perhaps fixed now as well, but the line speed went back up), the initial "express" behavior produced an even more interesting anomaly: once the speed averages came down into the kilobit range, one could click on "automatic" or "1 Mb" and get a message about it not being possible to perform tests outside a predefined range. The user thought something outside that range was being selected, but the system thought otherwise

For those of us who are likely to be making tests from machines with different performance behavior, on different LANs, with different ISPs, etc., it would help in tracking statistics if one could add a short comment to each test as it was recorded in the logs. I'd think that 100, or even 20 or 30, characters would be sufficient. If you were concerned about the content of those comments, make them visible only to (and exportable by) the member who ran the test and created the comment. They are likely to be useful only to those who know what convention they are using anyway. thanks.

Hi. The relatively new "Express" feature -- starting with some typical speed and then working up or down -- is a good idea operationally and statistically but iff the tests on which it is estimated are quite stable. In a situation (like the one I'm tryng to debug) in which speeds are fluctuating wildly (e.g., circa 80% of download readings in the 9-12 mpbs range but the other 20% clustering around 15-20 kbps, working from an average is a disaster. I'm seeing automatic tests starting with 7 MB downloads simply stall with several hours at less than 50%. If there were an effective and very quick downgrade procedure, that might still be ok, but whatever downgrade procedure is built in seems (from observation) to be based, not on a timer, but on having the initial data download complete. To save comments about the connection itself (more on that when I figure out what is going on), I've had packet analysers on both the LAN and between the local router and the cable modem and they are seeing fairly consistent local traffic density except when tests are being run. Running your tests from multiple computers on the LAN and use of different testing procedure yield roughly consistent results (the numbers my be different, but the wide fluctuations (and when they occur) are consistent. IMO, there needs to be a way to easily disable the "Express" mechanism. Even if you fix the downgrade procedure, there will probably always be edge cases extreme enough for it to fail.