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-----

_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • NFS / SMB / FUSE
    ... Hash: SHA1 ... if these were the big problems in life, ... I have a small network at home, and actually I have these three ...
    (freebsd-questions)
  • Re: NIC Card???
    ... > Hash: SHA1 ... > I am trying to get build a gateway/router on my network and I need to ...
    (comp.os.linux.networking)
  • Re: NIC Card???
    ... > Hash: SHA1 ... > I am trying to get build a gateway/router on my network and I need to ...
    (comp.os.linux.hardware)
  • Re: VNC ? again
    ... Hash: SHA1 ... Wade Smart wrote: ... able to control the screen - the mouse, point and click, etc, to show ...
    (Ubuntu)
  • Re: tcp wrapper vs xinetd
    ... Hash: SHA1 ... > control on the source adress. ...
    (comp.os.linux.networking)