Geekzone: technology news, blogs, forums
Guest
Welcome Guest.
You haven't logged in yet. If you don't have an account you can register now.




40 posts

Geek


Topic # 14876 24-Jul-2007 20:59
Send private message

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.

View this topic in a long page with up to 500 replies per page Create new topic
 1 | 2
3594 posts

Uber Geek
+1 received by user: 79

Trusted
WorldxChange

  Reply # 79532 25-Jul-2007 07:21
Send private message

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%SentRecvBestAvrgWrstLast
192.168.1.10848401320
10.10.40.545847907320
10.10.40.558847801512516
ip202-27-218-129.satlan.co.nz984770176216
compo.satlan.com5848015246216
202.27.202.17428483153512531
kccs.ape.net.nz11847415337816
wxc1.ape.net.nz108375153614016
lt-1-1-0.431.jcore1.wxnz.net138373153714131
pan.wxnz.net78378153714031

WinMTR statistics
078233133 200707141200

Host%SentRecvBestAvrgWrstLast
192.168.1.10606000160
10.10.40.545605707470
10.10.40.55960540146315
ip202-27-218-129.satlan.co.nz1560510144715
compo.satlan.com12605315256215
202.27.202.17426059153925015
kccs.ape.net.nz9605415337847
wxc1.ape.net.nz22604715377815
lt-1-1-0.431.jcore1.wxnz.net19604915379331
pan.wxnz.net16605015359432
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 Wink

             

https://www.facebook.com/wxccommunications

3594 posts

Uber Geek
+1 received by user: 79

Trusted
WorldxChange

  Reply # 79643 25-Jul-2007 16:56
Send private message

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 Wink

             

https://www.facebook.com/wxccommunications

 
 
 
 




40 posts

Geek


  Reply # 79693 25-Jul-2007 22:56
Send private message

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.



3594 posts

Uber Geek
+1 received by user: 79

Trusted
WorldxChange

  Reply # 79716 26-Jul-2007 07:46
Send private message

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


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,


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%SentRecvBestAvrgWrstLast
192.168.1.10606000160
10.10.40.545605707470
10.10.40.55960540146315
ip202-27-218-129.satlan.co.nz1560510144715
compo.satlan.com12605315256215


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 Wink

             

https://www.facebook.com/wxccommunications



40 posts

Geek


  Reply # 79914 26-Jul-2007 23:34
Send private message

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.

3594 posts

Uber Geek
+1 received by user: 79

Trusted
WorldxChange

  Reply # 79923 27-Jul-2007 06:46
Send private message

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 Wink

             

https://www.facebook.com/wxccommunications

3594 posts

Uber Geek
+1 received by user: 79

Trusted
WorldxChange

  Reply # 79982 27-Jul-2007 13:30
Send private message

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 Wink

             

https://www.facebook.com/wxccommunications



40 posts

Geek


  Reply # 79994 27-Jul-2007 15:05
Send private message

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


:-)
:-)



40 posts

Geek


  Reply # 79996 27-Jul-2007 15:10
Send private message

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.

3594 posts

Uber Geek
+1 received by user: 79

Trusted
WorldxChange

  Reply # 80031 27-Jul-2007 17:13
Send private message

13 proud years serving my Country Laughing (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 Wink




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

             

https://www.facebook.com/wxccommunications



40 posts

Geek


  Reply # 80093 28-Jul-2007 10:12
Send private message

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




40 posts

Geek


  Reply # 80107 28-Jul-2007 12:48
Send private message

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




40 posts

Geek


  Reply # 80110 28-Jul-2007 13:02
Send private message

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




40 posts

Geek


  Reply # 80162 28-Jul-2007 23:17
Send private message

 

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




40 posts

Geek


  Reply # 80225 29-Jul-2007 15:08
Send private message

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
View this topic in a long page with up to 500 replies per page Create new topic



Twitter »

Follow us to receive Twitter updates when new discussions are posted in our forums:



Follow us to receive Twitter updates when news items and blogs are posted in our frontpage:



Follow us to receive Twitter updates when tech item prices are listed in our price comparison site:



Geekzone Live »

Try automatic live updates from Geekzone directly in your browser, without refreshing the page, with Geekzone Live now.


Geekzone Live »

Our community of supporters help make Geekzone possible. Click the button below to join them.

Support Geezone on PressPatron



Are you subscribed to our RSS feed? You can download the latest headlines and summaries from our stories directly to your computer or smartphone by using a feed reader.

Alternatively, you can receive a daily email with Geekzone updates.