Re: who do I report this to?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

韓家標 Bill Hacker wrote:
> Aryeh M. Friedman wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>>> To be fair, Aryeh - your report was of a sort that indicated it
>>> could very well have been an upstream issue. Torrents in particular
>>> are unpredictable critters, and - given you've said you had only the
>>> one box - I don't see how/where you could have emulated that
>>> 'locally'.
>>
>> If it wasn't for the following facts (which where in the orginal
>> message and/or the immediate followup to Pyun):
>>
>>     * All applications are effected for example here is something that
>> happened earlier tonight (if I was organized I could of copied many of
>> these over the last few days [was doing a portupgrade -afk] but this
>> is the only one I copied):
>>
>>  >
>>  > => Attempting to fetch from
>>  > http://heanet.dl.sourceforge.net/sourceforge/xine/.
>>  > xine-lib-1.1.7.tar.gz                           9% of 8660 kB   40
>>  > kBps 03m13s
>>  > fetch: xine-lib-1.1.7.tar.gz appears to be truncated:
>> 868700/8868650 bytes
>>
>>     FTP also was sending garbagged data
>> 
>>
>
> Do a traceroute to that server from your 'seat' at one-hour intervals.
>
> Then do so from the looking-glass server on/near its own backbone.
>
> Meanwhile, there are plenty of compliants about the spotty
> performance of your local bandwidth provider. You'll find those
> online if you look.

My roommates XP machine seems to have none of these issues and it is
on the same net (there are two nets in the house but the other one is
unaccessible/modifiable by me)... also when I run the machine with
FreeBSD on it under vista no issue either.
>
>>     * It is time triggered plus to some extent the only common
>> denominator being time and re(4)
>>
>
> Not so. The common denominator throughout has been your *external
> link*.
>
> I can suggest a number of ways to quantize its characteristics, but
> it *doesn't matter*. They change over time and are not under your
> control.
>
> If you want to provide meaningful traffic tests on a NIC, you must
> get that unpredictable portion out of the mix!

Personally I think the unpredictable parts are part of the issue since
as you said you have pretty much the same setup and no issue... thus
the only way to do a local test I can think of is write a network
simulator and throw in different loss characteristics
>
> You will need at least one other 'local' box. It need not be fancy,
> but it has to be under your observation and control.

If the XP machine above will do (keep in mind I can make minor
alterations to it but I will be skinned alive if I do anything like
install an OS)
>
>>     * Rebooting the FreeBSD machine [static IP and DMZ] (and nothing
>> else on the network) always solves the problem
>
> There are plenty of reasons unrelated to the re (or any other)
> driver that can contribute to that. There is more to the world than
> driver code.

That is what the original post was asking but Pyun (and most other
private replies I have gotten) point to re(4)
>
>>> As to the re(4) 'issue' - we are scp'ing seriously large container
>>> files over local switches internal to the rack, AND both
>>> carrier-grade and sod-awful residential cable-modem links, csuping
>>> often, etc --- all  w/o *any* of the reported 're' problems (so far).
>>
>
>> This seems to only have appeared recently in 8-current (say last two
>> weeks or so)
>
> It may well have.  Or just as easily NOT.

Some of the scheduling changes in the last few days seem to have
improved stuff noticeably (issue still arises but no where near as often)
>
> You are not equipped to ascertain that.

I admit that
>
>>> Meanwhile - more accurate / detailed research & reporting, and a bit
>>> less sarcasm would be useful.
>>
>> If you can tell me how to capture a phantom I would be able to do
>> this.
>>
>
> What you are calling a 'phantom' is the product of a combination of
> circumstances - too many of which are literally 'outside the house'.

this very well be true but the lack of problems on vista/xp says other
wise I think.

>
> Fault isolation on networks is a precise science.

That I do know since in a past life I wrote some transport protocols
(ecip.org)
>
> The most basic part is fault *isolation*.
>
> IOW - you have to break the link down into its components, and test
> each part of the link from each end.
>
> If you can get down to a back-to-back CAT5E between two Gig-E NICs
> each on a *BSD box, and/or a single, 'decent', GigE switching hub
> between, then you can tcpdump both ends, set up a dummynet and
> emulate marginal links, run test suites with known characteristics -
> whatever it takes.

The only thing I have for this is the XP machine and Belkin router.

>
> Having your erratic uplink in the mix is not helping anyone.

Erratic uplink has yet to be proven as evidenced by the MS machines.

- --
Aryeh M. Friedman
Developer, not business, friendly
http://www.flosoft-systems.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHRi7YJ9+1V27SttsRAjCWAJ41uT3+6r7XBGU/94m9DeI0HVAydgCdEenZ
G9crcAMVW0foM87fweUhIyk=
=HW+0
-----END PGP SIGNATURE-----