Hi, Richard, usually packet-loss is quite 'normal' and followed by a resend, otherwise download's would (only)have 1 chance, of gettin through,
or the download has to start all over again, IMHO.
Does anyone have a clue as to what has been happening, the last day's?

---

At 12.52 UTC pathping returned all goose-eggs from here, and 12 minutes later it showed errors again.

Which seems to indicate that router was running right below its error threshold on the first test, and was above threshold during the 2nd (busier?) test.

Martin

added:
We do know a lot of people sent and received data yesterday without noticing much impact, so if the path/router is having real problems, it probably isn't that much of an impact.

Hi, pinged the path to boinc2.ssl.berkeley.edu but results are the same as
before the 'congestion'!

Busy tracing route to boinc2.ssl.berkeley.edu [208.68.240.18]
via maximaal 30 hops:
0 Leisure [192.168.2.2]
1 192.168.2.1
2 195.190.249.32
3 iawxsrt-rt2-bb21-ge-3-1-0.wxs.nl [213.75.64.145]
4 ams-ix.he.net [195.69.145.150]
5 10gigabitethernet4-1.core1.nyc4.he.net [216.66.24.153]
6 10gigabitethernet1-2.core1.chi1.he.net [72.52.92.102]
7 10gigabitethernet3-2.core1.sjc2.he.net [72.52.92.73]
8 10gigabitethernet3-2.core1.pao1.he.net [72.52.92.69]
9 64.71.140.42
10 208.68.243.254
11 boinc2.ssl.berkeley.edu [208.68.240.18]

Statistics being calculated for 275 second's....
From source/endpoint. And connection points.
Hop RTT Verl./verzonden Verloren/verz. Adres
0 Leisure [192.168.2.2]
0/ 100 = 0% |
1 7ms 0/ 100 = 0% 0/ 100 = 0% 192.168.2.1
0/ 100 = 0% |
2 --- 100/ 100 =100% 100/ 100 =100% 195.190.249.32
0/ 100 = 0% |
3 35ms 0/ 100 = 0% 0/ 100 = 0% iawxsrt-rt2-bb21-ge-3-1-0.wxs.nl [213.75.64.145]
0/ 100 = 0% |
4 33ms 0/ 100 = 0% 0/ 100 = 0% ams-ix.he.net [195.69.145.150]
0/ 100 = 0% |
5 122ms 0/ 100 = 0% 0/ 100 = 0% 10gigabitethernet4-1.core1.nyc4.he.net [216.66.24.153]
0/ 100 = 0% |
6 145ms 0/ 100 = 0% 0/ 100 = 0% 10gigabitethernet1-2.core1.chi1.he.net [72.52.92.102]
0/ 100 = 0% |
7 198ms 0/ 100 = 0% 0/ 100 = 0% 10gigabitethernet3-2.core1.sjc2.he.net [72.52.92.73]
0/ 100 = 0% |
8 199ms 0/ 100 = 0% 0/ 100 = 0% 10gigabitethernet3-2.core1.pao1.he.net [72.52.92.69]
1/ 100 = 1% |
9 199ms 1/ 100 = 1% 0/ 100 = 0% 64.71.140.42
10/ 100 = 10% |
10 266ms 11/ 100 = 11% 0/ 100 = 0% 208.68.243.254
6/ 100 = 6% |
11 268ms 17/ 100 = 17% 0/ 100 = 0% boinc2.ssl.berkeley.edu [208.68.240.18]

Trace is completed
Don't see any difference, so this is not a reliable way to check to connection, IMHO.

I don't see how hammering a connection that is having issues with diagnostics helps either.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

I don't see how hammering a connection that is having issues with diagnostics helps either.

You might get a better picture of what 'the issues' are?

Regards,
John.

I don't see how hammering a connection that is having issues with diagnostics helps either.

You might get a better picture of what 'the issues' are?

Regards,
John.

Hi John, that ofcoarse is the reason for this 'check', before/during and after, the upload issues. :)

---

@Hal - You could be right, though I suspect pathping is a fairly light "hammer". I know I saw a post somewhere that said there was a router in SETI-land that failed to carry it's load (again) or something to that effect, but danged if I can find that post a 2nd time...

I have modified my pathping command so only public routers (i.e. non-SETI) get pinged: "pathping -n 208.68.243.254". edited "-n" just removes router names.

The latest result a few mins ago - 19% failed. Highest rate I've seen.

Martin
edited...
"No rain drop blames itself for the flood" anonymous

Update - I haven't seen any errors so far today after 3 pathping checks.

Martin