 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Try 'ping -i 60 www.google.com >> pingfile.txt'
In the end I set up a small script to output the date/time and then the
result of 5 pings, this then gets run every minute by cron. I then wrote
a small C# program on my windows box to grab the log from the pi and
process it into CSV format for general graphing and analysis in Excel.
It's only a few regex's but my Linux knowledge is limited so would have
spent hours trying to do it on the pi. Also my BT modem handily has a
USB socket on the back which I can power the pi from, so it's all pretty
neat.
As you can imagine though there were no errors at all since Friday
evening when I got it running. 1 ping was not received out of about 15k
sent, and the response times were all pretty normal. BT did indeed phone
back when they promised (I even got a text to remind me) but of course
their comment was that the line is stable. I did persuade them to carry
on their "test" for another 5 days, I hope it breaks during this time.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 17/03/14 13:47, scott wrote:
>> Try 'ping -i 60 www.google.com >> pingfile.txt'
>
> In the end I set up a small script to output the date/time and then the
> result of 5 pings, this then gets run every minute by cron. I then wrote
> a small C# program on my windows box to grab the log from the pi and
> process it into CSV format for general graphing and analysis in Excel.
> It's only a few regex's but my Linux knowledge is limited so would have
> spent hours trying to do it on the pi. Also my BT modem handily has a
> USB socket on the back which I can power the pi from, so it's all pretty
> neat.
>
That's one way of doing it. ;-)
> As you can imagine though there were no errors at all since Friday
> evening when I got it running. 1 ping was not received out of about 15k
> sent, and the response times were all pretty normal. BT did indeed phone
> back when they promised (I even got a text to remind me) but of course
> their comment was that the line is stable. I did persuade them to carry
> on their "test" for another 5 days, I hope it breaks during this time.
>
I'm amazed you managed to persuade them to carry on testing for another
5 days. I'm not sure whether to hope it does break or whether to hope
that an intermittent fault has fixed itself.
John
--
Protect the Earth
It was not given to you by your parents
You hold it in trust for your children
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 17/03/2014 01:47 PM, scott wrote:
>> Try 'ping -i 60 www.google.com >> pingfile.txt'
>
> In the end I set up a small script to output the date/time and then the
> result of 5 pings, this then gets run every minute by cron. I then wrote
> a small C# program on my windows box to grab the log from the pi and
> process it into CSV format for general graphing and analysis in Excel.
> It's only a few regex's but my Linux knowledge is limited so would have
> spent hours trying to do it on the pi. Also my BT modem handily has a
> USB socket on the back which I can power the pi from, so it's all pretty
> neat.
At my last place, I ended up writing a small Tcl/Tk script to do more or
less the same thing (but with trippy statistics like standard
deviation). I also wrote a script to do trace-route against half a dozen
Internet hosts so if the link went down, I could tell where it went
down. (Half the problem with spotting fault behaviour is knowing what
normal behaviour looks like.)
And then our HQ IT guys blocked all ICMP traffic at the firewall, and
all my hard work was rendered useless. Thanks, guys.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 17/03/2014 06:38 PM, Orchid Win7 v1 wrote:
> And then our HQ IT guys blocked all ICMP traffic at the firewall, and
> all my hard work was rendered useless. Thanks, guys.
Why no, I'm not still bitter about my last job. Why do you ask?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 17/03/2014 6:42 PM, Orchid Win7 v1 wrote:
> On 17/03/2014 06:38 PM, Orchid Win7 v1 wrote:
>> And then our HQ IT guys blocked all ICMP traffic at the firewall, and
>> all my hard work was rendered useless. Thanks, guys.
>
> Why no, I'm not still bitter about my last job. Why do you ask?
Because being undervalued is embittering?
--
Regards
Stephen
I solemnly promise to kick the next angle, I see.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 17 Mar 2014 20:04:58 +0000, Stephen wrote:
> On 17/03/2014 6:42 PM, Orchid Win7 v1 wrote:
>> On 17/03/2014 06:38 PM, Orchid Win7 v1 wrote:
>>> And then our HQ IT guys blocked all ICMP traffic at the firewall, and
>>> all my hard work was rendered useless. Thanks, guys.
>>
>> Why no, I'm not still bitter about my last job. Why do you ask?
>
> Because being undervalued is embittering?
Absolutely.
Jim
--
"I learned long ago, never to wrestle with a pig. You get dirty, and
besides, the pig likes it." - George Bernard Shaw
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I'm amazed you managed to persuade them to carry on testing for another
> 5 days. I'm not sure whether to hope it does break or whether to hope
> that an intermittent fault has fixed itself.
It's very intermittent, I've only noticed it happening for periods of
15-30 mins every week or so, it's been going on for months, maybe
longer. I only really noticed it when I started playing iRacing
seriously and it really messes things up if your connection repeatedly
drops - imagine racing close behind someone who then disappears for a
second or so, then reappears not quite where you expected them to be :-O
Also the software dumps you back to the pits if you disconnect for more
than a few seconds, which is bad for your rating (complete disconnect or
quit counts as finishing last).
I even tried my old Sky modem for a while and the same thing happened.
Interestingly I got closer to a reported 4 mbit connection with the Sky
modem, usually I get just under 3 mbit with the BT one. Thought I better
switch it back to the BT one before calling them though...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> At my last place, I ended up writing a small Tcl/Tk script to do more or
> less the same thing (but with trippy statistics like standard
> deviation). I also wrote a script to do trace-route against half a dozen
> Internet hosts so if the link went down, I could tell where it went
> down. (Half the problem with spotting fault behaviour is knowing what
> normal behaviour looks like.)
Well on my modem "normal" behaviour is a ping of about 35 ms to google
and 5 packets received out of 5 sent. Above 100 ms or less than 5
received is not normal.
So just to update, after 3 calls to India an actual physical real person
came round to my house to have a look. He tested the line from the
socket and also the outside of the house and said actually the line was
better than average. He replaced the wall socket and gave me a new modem
anyway to rule those out, but couldn't find any problem at all with the
line. Interestingly initially the modem was connected at 5mbit instead
of the normal 3, and ping was down to under 20ms to google. But after a
few hours the ping suddenly jumped back up to 35ms, and the speed has
gradually come down to about 4.5mbit now.
He had a chart on his laptop that showed the connection quality for the
last 14 days, and the red blocks matched my chart :-) But he had no idea
why it was behaving like that :-( At the moment I can't be bothered to
take another 1/2 day off work just to be told the same again, but I'll
continue to keep logging...
I suppose ideally he would leave his DSL analyser box thingy connected
to the line for a few days until it drops, but BT probably don't do that
for a mere residential customer.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 26/03/14 11:27, scott wrote:
> Well on my modem "normal" behaviour is a ping of about 35 ms to google
> and 5 packets received out of 5 sent. Above 100 ms or less than 5
> received is not normal.
>
On my slowest machine:
--- www.google.com ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6010ms
rtt min/avg/max/mdev = 6.985/7.721/8.708/0.578 ms
>
> I suppose ideally he would leave his DSL analyser box thingy connected
> to the line for a few days until it drops, but BT probably don't do that
> for a mere residential customer.
>
My real person was prepared to do so if he hadn't found the corroded
terminals. Maybe a quick note to Warren Buckley's office is called for
John
--
Protect the Earth
It was not given to you by your parents
You hold it in trust for your children
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> On my slowest machine:
> --- www.google.com ping statistics ---
> 7 packets transmitted, 7 received, 0% packet loss, time 6010ms
> rtt min/avg/max/mdev = 6.985/7.721/8.708/0.578 ms
It doesn't seem to make any difference which machine it's on, or whether
it's wifi or wired, the first hop on tracert to the modem is always 1 or
2 ms, then the 2nd hop (presumably to a BT server) is up to 30+ ms, so
that is where the bottleneck is. When it "goes slow" just before or
after dropping out it's always the first hop after my modem that shows
the huge delay.
> My real person was prepared to do so if he hadn't found the corroded
> terminals.
I'll leave it logging for a week or two so I have some significant data
to show, so far though the phone support has been fine. Each time they
answered within a couple of minutes and called back exactly when they
said they would after doing tests.
> Maybe a quick note to Warren Buckley's office is called for
I'll keep that as a last resort!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
