[WXC/VFX] SPA2102 QoS Skynet wireless WRT54GL

Forums › One New Zealand (including Vodafone, WxC, Farmside) › [WXC/VFX] SPA2102 QoS Skynet wireless WRT54GL

wldhrs

40 posts

Geek

#14876 24-Jul-2007 20:59

Standard wireless analog phone plugged into a SPA2102, plugged into a WRT54GL running dd-wrt, plugged into Skynet's network.

Doesn't work. Most of the time. The voice link is randomly unidirectional, randomly neitherdirectional, seldom even as good as a bad cellphone call in both directions.

Found a forum entry http://www.geekzone.co.nz/forums.asp?forumid=65&topicid=11825 back in February about an IPStar link with similar symptoms, but there's been no updates since February.

Have played with a bunch of freeware tools, finally paid for a copy of VisualRoute, to watch the network between here and pan.wxnz.net. The only consistent results are that latency and packet loss on the CityLink peering exchange servers and WXC's servers are uncool for a while after session setup, closely followed by KCCS and Satlan servers. The link from here to the other side of Skynet's wireless network has the odd randomly bad period but nothing consistently bad.

From my last conversation with the WXC helpdesk, the 2102 uses the G711 codec, which appears to be the Cisco/Linksys recommendation, but I've not yet tracked down if the codec is also recommended for the sort of twittery network that this one appears to be. I'm starting to suspect G711 isn't a good choice to start from if there are latency or loss issues.

The answers I'm getting from the WXC helpdesk are quite consistent, it's not our problem, not our servers, but send us more traces and we can help. And it's not cheap sitting on hold with my cell phone cos the voip line is unusable.

Not cool, WXC, you've had some very good press around the blogs, but I'm having a lot of trouble with believing I'm the only one to have had this problem on a wireless network and that I've got to debug it if I want a solution.

1 | 2

3594 posts

Uber Geek

Trusted

WorldxChange

#79532 25-Jul-2007 07:21

Thanks for the info and actually I am aware of this issue as the support person has raised this issue with our Operations Group,

Firstly let me say that it is pretty difficult to fix an issue when we have no control over the access on how it gets to us, also you will be using G729a generally by defualt as this handles Latency and Jitter much better, you are correct though G711 doesn’t handle those types of latency Jitter issues very well.

however the problem we see here with your Skynet connection is not latency or jitter but dropped packets, if a single packet gets lost then generally you won't notice it but to many and you will have bad audio which is what you are reporting and what we are seeing is lost packets, now thanks for supplying the traces as this is the only way that we can see the actual path your connection takes to get to us, with there being so many different internet providers in NZ there will be different routes for getting to different parts of the network and we will not be able to see how you get to us with out this info.

I will show 3 traces from 3 different DSL connections we have in the test area here, now what these show is that via the Network Path that they take to get to pan.wxnz.net all packets where sent and received across 3 different connections so all results look good with no packet loss, so basically calls over this should be ok as the ping times look pretty good as well as packets being passed and not lost, this is only a basic check but needs to be done to check the actual connection.

Test DSL1
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| RTA1320.home - 0 | 101 | 101 | 0 | 0 | 15 | 0 |
| int-l32-akl-dsl01.wxnz.net - 0 | 101 | 101 | 0 | 15 | 30 | 15 |
| ge-1-0-0-57-jcore3.wxnz.net - 0 | 101 | 101 | 0 | 11 | 32 | 15 |
| ge-0-0-0-akl-core2.wxnz.net - 0 | 101 | 101 | 0 | 13 | 34 | 16 |
| lt-1-1-0.431.jcore1.wxnz.net - 0 | 101 | 101 | 0 | 11 | 31 | 16 |
| pan.wxnz.net - 0 | 101 | 101 | 0 | 15 | 36 | 16 |
|________________________________________________|______|______|______|______|______|______|
WinMTR - 0.8. Copyleft @2000-2002 Vasile Laurentiu Stanimir ( stanimir@cr.nivis.com ) Test DSL2
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.1.1 - 0 | 126 | 126 | 0 | 0 | 16 | 0 |
| int-l32-akl-dsl01.wxnz.net - 0 | 126 | 126 | 15 | 17 | 47 | 16 |
| ge-1-0-0-57-jcore3.wxnz.net - 0 | 125 | 125 | 15 | 17 | 62 | 16 |
| ge-0-0-0-akl-core2.wxnz.net - 0 | 125 | 125 | 15 | 18 | 32 | 16 |
| lt-1-1-0.431.jcore1.wxnz.net - 0 | 125 | 125 | 15 | 17 | 32 | 15 |
| pan.wxnz.net - 0 | 125 | 125 | 15 | 17 | 32 | 15 |
|________________________________________________|______|______|______|______|______|______|
WinMTR - 0.8. Copyleft @2000-2002 Vasile Laurentiu Stanimir ( stanimir@cr.nivis.com )
Test DSL3
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.1.1 - 0 | 102 | 102 | 0 | 1 | 16 | 0 |
| int-l32-akl-dsl01.wxnz.net - 0 | 102 | 102 | 15 | 18 | 93 | 16 |
| ge-1-0-0-57-jcore3.wxnz.net - 0 | 102 | 102 | 15 | 17 | 47 | 16 |
| ge-0-0-0-akl-core2.wxnz.net - 0 | 101 | 101 | 15 | 19 | 47 | 16 |
| lt-1-1-0.431.jcore1.wxnz.net - 0 | 101 | 101 | 15 | 16 | 32 | 15 |
| pan.wxnz.net - 0 | 101 | 101 | 15 | 18 | 32 | 16 |
|________________________________________________|______|______|______|______|______|______|
WinMTR - 0.8. Copyleft @2000-2002 Vasile Laurentiu Stanimir ( stanimir@cr.nivis.com )

Now we move to the traces you supplied us, now straight away the problem stands out, a large amount of packet loss, yes I know it's always easier to point the finger at someone else but here we do see right from your very first connection 10.10.40.54 you are already dropping 5 to 10 % of the packets, you havent even gone past the first HOP , you have to remember that the issue will be cumulative if your dropping packets from the first HOP that is also going to effect the last hops as the packets are getting dropped before they get to you

WinMTR statistics
078233133 200707200945

Host	%	Sent	Recv	Best	Avrg	Wrst	Last
192.168.1.1	0	84	84	0	1	32	0
10.10.40.54	5	84	79	0	7	32	0
10.10.40.55	8	84	78	0	15	125	16
ip202-27-218-129.satlan.co.nz	9	84	77	0	17	62	16
compo.satlan.com	5	84	80	15	24	62	16
202.27.202.174	2	84	83	15	35	125	31
kccs.ape.net.nz	11	84	74	15	33	78	16
wxc1.ape.net.nz	10	83	75	15	36	140	16
lt-1-1-0.431.jcore1.wxnz.net	13	83	73	15	37	141	31
pan.wxnz.net	7	83	78	15	37	140	31

WinMTR statistics
078233133 200707141200

Host	%	Sent	Recv	Best	Avrg	Wrst	Last
192.168.1.1	0	60	60	0	0	16	0
10.10.40.54	5	60	57	0	7	47	0
10.10.40.55	9	60	54	0	14	63	15
ip202-27-218-129.satlan.co.nz	15	60	51	0	14	47	15
compo.satlan.com	12	60	53	15	25	62	15
202.27.202.174	2	60	59	15	39	250	15
kccs.ape.net.nz	9	60	54	15	33	78	47
wxc1.ape.net.nz	22	60	47	15	37	78	15
lt-1-1-0.431.jcore1.wxnz.net	19	60	49	15	37	93	31
pan.wxnz.net	16	60	50	15	35	94	32

I myself am on a wireless connection running a wrtp54g and last night was doing some work and ran these same tests for something else I was working and did not see anywhere near this type of packet loss, so unfortunately we don't control Skynets access or how they connect to the IP peering, we can only try and assist in finding the problem and try to help in getting it resolved. If you ran the same tests except go to 202.27.218.129 I would expect you will still have packet loss, So our suggestion was give these results and the ones you run to 202.27.218.129 to your ISP and see if they have any suggestions, If this was a network problem and not a Access problem then yes you would be right the forums would be flooded with complaints. Don't get me wrong we do get them but they are a very small minority and almost 100% of them are due to access.

Yes I am a employee of WxC (My Profile) ... but I do have my own opinions as well

https://www.facebook.com/wxccommunications

maverick

3594 posts

Uber Geek

Trusted

WorldxChange

#79643 25-Jul-2007 16:56

Now that I am home I can show the results to our Network from my wireless connection (Wired Country in case you wondered) and here they are, now you will notice that the last 3 hops are basically the same as yours yet no packet loss, and no packet loss through the first 2 Hops ,whereas your connection shows drops right from the first Hop.

|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent| Recv| Best | Avrg| Wrst | Last |
|----------------------------------------------- -|------|------|------|------|------|------|
| 192.168.15.1 - 0 | 306 | 306| 0 | 0 | 10 | 0 |
| wcterm7200.network.compass.net.nz - 0 | 306 | 306| 10 | 17 | 70 | 20 |
| 10.254.254.7 - 0 | 306 | 306| 10 | 17| 61 | 10 |
| wxc2.ape.net.nz - 0 | 306 | 306| 20 | 49 | 200| 30 |
| ge-0-0-0-akl-core3.wxnz.net - 0 | 306 | 306| 10 | 20 | 70| 10 |
| pan.wxnz.net - 0 | 306 | 306| 10 | 18 | 80| 20 |
|________________________________________________|______|______|______|______|______|______|
WinMTR - 0.8. Copyleft @2000-2002 Vasile Laurentiu Stanimir ( stanimir@cr.nivis.com )

If there was a standout problem with our network connection what I would expect to see is no packet loss in the first through HOPS through Skynet and then Packet loss once it hits our network elements but the problem is that we are seeing Packet loss right from the start sorry which appears to be your providers network.

I hope I have explained this well enough for you, and we are not just trying to make you debug the problem, we are trying to explain the issue so you can take it up with your wireless provider so that they can assist you because we don't believe we can fix the issue from here.

Yes I am a employee of WxC (My Profile) ... but I do have my own opinions as well

https://www.facebook.com/wxccommunications

wldhrs

40 posts

Geek

#79693 25-Jul-2007 22:56

Ok maverick, thanks for the time you're putting in here.

As everyone here understands intuitively that all network problems multiply by an order of magnitude when each additional hardware or software provider enters the sequence, and the possibility of gaining a resolution to a network problem decreases logarithmically as each additional provider becomes involved in the resolution process, and we're dealing here with an exGeek, Skynet, Satlan, KCCS, Citylink and WXC, then it's obvious that no resolution will be possible until 4 January 2037.

Moreover, my wife and kids require a resolution or return to a landline by EOB tomorrow.

So in the interest of controlled folly or suspension of disbelief or whatever pragmatic framework you use to achieve the impossible on a daily basis, let's get some science and some heuristics into the process here.

The choice of codec is important.

Are G711 and G729 the only codecs available for the SPA2102 from WXC?

Are G711 and G729 the only codecs available for the SPA2102?

Is there more than one variant of each of these codecs available, G711a G711u or the like?

Is G729a probably most suited to the network we're dealing with?

Packet loss is important.

The more packets lost, the worse the result. Heuristically, fix the big loss servers first. This is where I disagree with maverick's approach, the figures I've come up with indicate the big losses are on WXC and APE servers.

I can talk with Skynet who can assure me their servers are cool.

I can talk with WXC who can assure me their servers are cool.

I can go round and round in circles trying to talk with Satlan, KCCS and Citylink who will assure me their servers are cool, because I'm not a player, just a punter.

I can use Skype from here to another Cambridge site and the results aren't too bad. Ok, I may be getting a bunch of randomly good low loss low latency periods.

I can use Slingshot's iTalk from here to landlines and my cellphone and the results aren't too bad. Ok, I may be getting a bunch of randomly good low loss low latency periods.

I can use WXC's VFX from here to landlines and well ... back to where we started. Ok, I may be getting a bunch of randomly bad high loss high latency periods.

Then one of -those- moments happened. The figures I'm producing are showing losses right through the network, the figures maverick is coming up with are showing no losses.

???

So I tried measuring the same thing different ways.

Using WinMTR I get losses reported, I think MTR uses ICMP and TCP to evaluate the network?

Using VisualRoute with ICMP I get losses reported.

Using VisualRoute with UDP I don't get losses reported and interestingly can't see pan.wxnz.net.

Using VisualRoute with ICMP and UDP I don't get losses reported, but can see pan.wxnz.net.

!!!

Now we're getting somewhere.

Running VisualRoute with ICMP to pan.wxnz.net and vip1.italk.co.nz gives consistent results. No losses on the Skynet wireless hops, low single digit losses on the Satlan and KCCS hops, double digit losses on the APE hops for both KCCS and Slingshot, then enormous variations from zero to double digit losses on the Slingshot and WXC servers.

Did ya notice that - NO losses on the wireless hops.

Well maybe we're not getting anywhere at all.

What are a reasonable set of measurements?

Should a tool that examines TCP packet losses be the only thing to believe?

Who's gonna talk to KCCS and Citylink?

And on a related subject, the WXC speed test web page looks a lot like the VisualRoute speed test, do WXC run the VisualRoute NOC version, cos this would let you run yer own traces from here to there instead of relying on me to fit in times around trying to earn a living.

Your serve maverick.

maverick

3594 posts

Uber Geek

Trusted

WorldxChange

#79716 26-Jul-2007 07:46

Hi Peter,

At his stage Codec has nothing to do with it, but for you info both G711 codec’s are supported as well as G729, you will see below that all your calls use G729 as I have said, G729 is used as it handles latency and Jitter better than others and yes packet loss is very important and in this case it is the Sole reason for the issue.

Here are some examples of what I am trying to explain from 2 separate connections on wireless providers the first is call from My connection using a Wired Country Connection, the following 4 are calls from you using your skynet connection.

Now what we see here is a 33 Minute (DU = Seconds) call via my wireless connection the reporting and QOS stats for this call shows that we sent 101411 Voice Packets the Linksys device reported that it lost 1 packet for that whole call PR= Packets Rxed PL = Packets Loss, this is what we generally see for good network connections and remember this is going through the same WorldxChange Network your calls go through the only difference is who is giving us the packets.

Media Type audio/g729a
uri mos timestamp packets-passed packets-dropped packets-lost current-jitter
9950xxxx 4.15 19:33:12.780 Tue 2007-07-24 101411 0 0 0.157

Media Type audio/g729
uri mos timestamp packets-passed packets-dropped packets-lost current-jitter
07386xxxx 4.14 19:33:12.780 Tue 2007-07-24 101429 0 2 0.263

Timestamp     : 19:33:12.776 2007-07-24
Direction     : RX
Remote IP/Port: 203.152.xxx.xxx/
Local IP/Port : 58.28.xxx.xxx/
Transport     : UDP
----------------------------------------
SIP/2.0 200 OK
To: 099501111;tag=ed2fc24f9b4ae4a6o0
From: ;tag=96141c3a-1f7c-46a5a34b-4596434c-7b606587
Call-ID: daff1e43-ee581942@203.152.98.140
CSeq: 4 BYE
Via: SIP/2.0/UDP 58.28.xxx.xxx;branch=z9hG4bK-46a5ab37-45b537b8-41fb9476
Server: WRTP54G-3.1.22
P-RTP-Stat: PS=101431,OS=3245782,PR=101410,OR=3244340,PL=1,JI=1,LA=0,DU=2019,EN=G729a,DE=G729a
Content-Length: 0

This is what we see for the 4 calls you made last Night , now all of these seem to have between 5 & 10% packet loss in both directions and this corresponds roughly to the information you gave us

CALL 1
Media Type audio/g729a
uri mos timestamp packets-passed packets-dropped packets-lost current-jitter
07929xxxx 3.58 08:50:00.282 Wed 2007-07-25 1593 0 154 0.514

Media Type audio/g729
uri mos timestamp packets-passed packets-dropped packets-lost current-jitter
7823xxxx 4.16 08:50:00.282 Wed 2007-07-25 1769 0 0 0.098

Timestamp     : 08:50:00.276 2007-07-25
Direction     : RX
Remote IP/Port: 202.27.xxx.xxx
Local IP/Port : 58.28.xxx.xxx
Transport     : UDP
----------------------------------------
BYE sip:07929xxxx@as.wxcnz.net:8060;maddr=58.28.xxx.xxx;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.1.173:8062;branch=z9hG4bK-ebdd5527;rport=8062
From: 07823xxxx ;tag=c9cee7dc22682bfdo0
To: ;tag=96141c3a-1f7c-46a665d3-488dff9c-3a2b8769
Call-ID: dba41088-f99f3b41@192.168.1.173
CSeq: 102 BYE
Max-Forwards: 70
User-Agent: Linksys/SPA2102-5.1.9
P-RTP-Stat: PS=1769,OS=35140,PR=1632,OR=32640,PL=137,JI=13,LA=0,DU=35,EN=G729a,DE=G729a
Content-Length: 0

CALL 2
Media Type audio/g729a
uri mos timestamp packets-passed packets-dropped packets-lost current-jitter
123 3.64 12:00:21.499 Wed 2007-07-25 978 0 76 0.678

Media Type audio/g729
uri mos timestamp packets-passed packets-dropped packets-lost current-jitter
7823xxxx 4.15 12:00:21.499 Wed 2007-07-25 1089 0 0 0.154

Timestamp     : 12:00:21.493 2007-07-25
Direction     : RX
Remote IP/Port: 202.27.xxx.xxx
Local IP/Port : 58.28.xxx.xxx
Transport     : UDP
----------------------------------------
BYE sip:123@as.wxcnz.net:;maddr=58.28.xxx.xxx;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.1.173:8062;branch=z9hG4bK-fe4b806b;rport=8062
From: 07823xxxx ;tag=716fb930eab4ddc4o0
To: ;tag=96141c3a-1f7c-46a6927e-493c7477-2941ded0
Call-ID: db4fea0-ce3ad714@192.168.1.173
CSeq: 102 BYE
Max-Forwards: 70
User-Agent: Linksys/SPA2102-5.1.9
P-RTP-Stat: PS=1065,OS=21300,PR=1007,OR=20140,PL=82,JI=9,LA=0,DU=20,EN=G729a,DE=G729a
Content-Length: 0

CALL 3
Media Type audio/g729a
uri mos timestamp packets-passed packets-dropped packets-lost current-jitter
0273xxx 3.51 16:59:07.333 Wed 2007-07-25 566 0 56 0.905

Media Type audio/g729
uri mos timestamp packets-passed packets-dropped packets-lost current-jitter
7823xxxx 4.15 16:59:07.333 Wed 2007-07-25 636 0 0 0.135

Timestamp     : 16:59:07.328 2007-07-25
Direction     : RX
Remote IP/Port: 202.27.xxx.xxx
Local IP/Port : 58.28.xxx.xxx
Transport     : UDP
----------------------------------------
BYE sip:02733xxxxx@as.wxcnz.net:;maddr=58.28.xxx.xxx;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.1.173:8062;branch=z9hG4bK-77d93083;rport=8062
From: 078233133 ;tag=88f2160112e89ccdo0
To: ;tag=96141c3a-1f7c-46a6d88d-4a4e0de4-50cd9375
Call-ID: 3466511-eb4218fd@192.168.1.173
CSeq: 102 BYE
Max-Forwards: 70
User-Agent: Linksys/SPA2102-5.1.9
P-RTP-Stat: PS=638,OS=12760,PR=598,OR=11960,PL=38,JI=14,LA=0,DU=10,EN=G729a,DE=G729a
Content-Length: 0

CALL 4

Media Type audio/g729a
uri    mos timestamp                              packets-passed packets-dropped packets-lost current-jitter
*62  3.56 19:52:37.173 Wed 2007-07-25 2824                0                       249             0.88
Media Type audio/g729
uri            mos timestamp                        packets-passed packets-dropped packets-lost current-jitter
7823xxxx 19:52:37.173 Wed 2007-07-25  4318                 0                       0                0.1

Timestamp     : 19:52:37.168 2007-07-25
Direction     : RX
Remote IP/Port: 202.27.xxx.xxx
Local IP/Port : 58.28.xxx.xxx
Transport     : UDP
----------------------------------------
BYE sip:*62@as.wxcnz.net:8060;maddr=58.28.xxx.xxx;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.1.173:8062;branch=z9hG4bK-90a04b45;rport=8062
From: 07823xxxx ;tag=5b9dfa95dad1a4aco0
To: ;tag=96141c3a-1f7c-46a700e7-4aeba716-82dff4b
Call-ID: 9ff7eb89-984d4848@192.168.1.173
CSeq: 102 BYE
Max-Forwards: 70
User-Agent: Linksys/SPA2102-5.1.9
P-RTP-Stat: PS=3109,OS=89890,PR=4070,OR=81400,PL=248,JI=7,LA=0,DU=93,EN=G729a,DE=G729a
Content-Length: 0

We are not trying to point the finger directly at Skynet it may be in their IP peering but the issue we believe is in this part of the network from the info you have given us the 5 to 10% loss we see is happening before it gets to us and after it leaves our core, please understand we have no direct arrangements with Skynet or whoever they use for IP peering we can’t fix something we have no control over Peter, you have the relationship with your ISP give them the details you have said your self

“Running VisualRoute with ICMP to pan.wxnz.net and vip1.italk.co.nz gives consistent results. No losses on the Skynet wireless hops, low single digit losses on the Satlan and KCCS hops, double digit losses on the APE hops for both KCCS and Slingshot, then enormous variations from zero to double digit losses on the Slingshot and WXC servers.”

Which corresponds to what we see 5 to 10% packet loss, here lies the issue Peter in these HOPS

Host	%	Sent	Recv	Best	Avrg	Wrst	Last
192.168.1.1	0	60	60	0	0	16	0
10.10.40.54	5	60	57	0	7	47	0
10.10.40.55	9	60	54	0	14	63	15
ip202-27-218-129.satlan.co.nz	15	60	51	0	14	47	15
compo.satlan.com	12	60	53	15	25	62	15

However the issue needs to go to them and since you have put a deadline of COB tomorrow sadly there is nothing I can do to help at this stage as we would probably not be able to help get this resolved in that timeframe , we will try and raise the issue but don't think we will get much headway … I wish I could be more help.

Yes I am a employee of WxC (My Profile) ... but I do have my own opinions as well

https://www.facebook.com/wxccommunications

wldhrs

40 posts

Geek

#79914 26-Jul-2007 23:34

Thanks again maverick. I've passed the link to this forum entry on to Skynet, along with a quick summary, will see what happens.

I noticed this morning that the SPA2102's line registration had fallen off and the pan.wxnz.net server wouldn't respond to pings for a while, but didn't have time to check further. Was this outage in the WXC network or the peering exchange?

Coincidentally, the calls that I've had today across the WXC voip network have been remarkably clear, to the extent that my wife is no longer threatening immediate mayhem, so I've got a day or two's reprieve before mandatory return to a landline :-)

Will keep you posted on response from Skynet.

maverick

3594 posts

Uber Geek

Trusted

WorldxChange

#79923 27-Jul-2007 06:46

Hi again Peter,

No changes here I'm afraid , my Engineering guys were trying to get in touch with a couple people were we think the issue is, I don't have an update from them as yet so not sure if there was any action, possibly may have been if you have seen an improvement but nothing from our end at this point, will advise here when I get an update.

If there was a massive amount of PING activity you may have been knocked off the network for a while as it may have been seen as a DDOS attack but no network issues here as far as were aware.

Yes I am a employee of WxC (My Profile) ... but I do have my own opinions as well

https://www.facebook.com/wxccommunications

maverick

3594 posts

Uber Geek

Trusted

WorldxChange

#79982 27-Jul-2007 13:30

We did manage to talk to someone today at kccs , they were advised of the issue Peter and I believe they did see some problems and will be looking at it.

Yes I am a employee of WxC (My Profile) ... but I do have my own opinions as well

https://www.facebook.com/wxccommunications

Sharesies kids

Free kids accounts - trade shares and funds (NZ, US) with Sharesies (affiliate link).

wldhrs

40 posts

Geek

#79994 27-Jul-2007 15:05

coooooool ... c000000001, (8 bits plus a parity bit, wha? that's EBCDIC, oops, gave away the game there) SNA P, what is this Inferior aPproximation of a network protocol?

Stateless Rulz

...HTML 1.1

oh sorry

Stateful Rulz

:-)
:-)

wldhrs

40 posts

Geek

#79996 27-Jul-2007 15:10

Unconnected side comment - how long have ya been around this diabolical industry Phil? You don't get your sort of experience in a couple of years.

maverick

3594 posts

Uber Geek

Trusted

WorldxChange

#80031 27-Jul-2007 17:13

13 proud years serving my Country

(NZ Army - Royal New Zealand Corp of Signals) + the last 15 years in the Telco Industry as are a lot of the Network Team here at WxC...we have been around for a while we just don't jump up and down about it

Yes I am a employee of WxC (My Profile) ... but I do have my own opinions as well

https://www.facebook.com/wxccommunications

wldhrs

40 posts

Geek

#80093 28-Jul-2007 10:12

Thought I'd noticed a little .mil cadence in the background of the posts there.

I'll put random WinMTR results up here as I have time to do them and see if any patterns pop up. Using WinMTR because it copies the results to HTML nicely.

A phone call just prior to these results was quite acceptable quality.

WinMTR statistics 200707281015

Host	%	Sent	Recv	Best	Avrg	Wrst	Last
192.168.1.1	0	61	61	0	0	16	0
10.10.41.53	0	61	61	0	5	63	0
10.10.41.54	0	60	60	0	7	46	15
10.10.40.55	0	60	60	0	11	47	0
ip202-27-218-129.satlan.co.nz	0	60	60	0	15	46	16
compo.satlan.com	5	60	57	15	24	94	32
202.27.202.174	4	60	58	15	27	125	32
kccs.ape.net.nz	10	60	54	15	30	78	62
wxc1.ape.net.nz	4	60	58	15	33	78	32
pan.wxnz.net	5	60	57	15	30	62	32

wldhrs

40 posts

Geek

#80107 28-Jul-2007 12:48

Forgot to stop this one - left it running for a couple of hours

WinMTR statistics 200707281245

Host	%	Sent	Recv	Best	Avrg	Wrst	Last
192.168.1.1	6	7924	7456	0	1	47	0
10.10.41.53	6	7924	7508	0	11	562	47
10.10.41.54	5	7924	7540	0	13	640	16
10.10.40.55	5	7923	7552	0	19	547	15
ip202-27-218-129.satlan.co.nz	1	7923	7887	0	23	922	15
compo.satlan.com	7	7923	7370	15	34	813	15
202.27.202.174	6	7923	7477	15	38	719	15
kccs.ape.net.nz	9	7923	7277	15	40	625	78
wxc1.ape.net.nz	9	7923	7265	15	41	641	31
pan.wxnz.net	9	7923	7236	15	40	562	31

wldhrs

40 posts

Geek

#80110 28-Jul-2007 13:02

Again, phone call just before this was good quality, only a little latency. Interesting that my router, 192.168.1.1 is the LAN side of the WRT54GL, dropped a packet :-)

WinMTR statistics 200707281255

Host	%	Sent	Recv	Best	Avrg	Wrst	Last
192.168.1.1	2	61	60	0	1	31	0
10.10.41.53	0	61	61	0	26	297	0
10.10.41.54	0	60	60	0	20	188	0
10.10.40.55	0	60	60	0	23	125	46
ip202-27-218-129.satlan.co.nz	0	60	60	0	28	203	0
compo.satlan.com	4	60	58	15	52	312	31
202.27.202.174	4	60	58	15	54	406	31
kccs.ape.net.nz	5	60	57	15	48	375	47
wxc1.ape.net.nz	4	60	58	15	55	266	32
pan.wxnz.net	6	60	56	15	53	234	93

wldhrs

40 posts

Geek

#80162 28-Jul-2007 23:17

WinMTR statistics 200707282315

Host	%	Sent	Recv	Best	Avrg	Wrst	Last
192.168.1.1	0	61	61	0	1	16	0
10.10.41.53	0	61	61	0	5	16	0
10.10.41.54	0	61	61	0	6	47	15
10.10.40.55	0	60	60	0	12	62	15
ip202-27-218-129.satlan.co.nz	0	60	60	0	21	250	15
compo.satlan.com	2	60	59	15	28	125	31
202.27.202.174	9	60	55	15	31	250	16
kccs.ape.net.nz	9	60	55	15	26	78	16
wxc1.ape.net.nz	5	60	57	15	29	62	32
pan.wxnz.net	7	60	56	15	28	62	16

wldhrs

40 posts

Geek

#80225 29-Jul-2007 15:08

Can't see the first hop of the wireless network, heavy cloud and rain, and the router reports 98 active connections so I'd expect a bit of packet slush at this end.

WinMTR statistics 200707291455

Host	%	Sent	Recv	Best	Avrg	Wrst	Last
192.168.1.1	0	61	61	0	3	31	0
10.10.41.53	4	61	58	46	483	2031	172
10.10.41.54	2	60	59	110	467	1938	188
10.10.40.55	2	60	59	31	501	1828	125
ip202-27-218-129.satlan.co.nz	0	60	60	15	519	1734	328
compo.satlan.com	5	60	57	46	523	1703	437
202.27.202.174	4	60	58	62	507	1578	344
kccs.ape.net.nz	14	60	52	31	449	1485	219
wxc1.ape.net.nz	7	60	56	31	469	1922	94
pan.wxnz.net	11	60	53	46	495	2109	235

1 | 2

WinMTR statistics 078233133 200707200945

WinMTR statistics 078233133 200707141200

WinMTR statistics
078233133 200707200945

WinMTR statistics
078233133 200707141200