Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: 1 2 [3] 4 5 ... 7

Author Topic: Could somebody check my logs and see if there any problems please  (Read 22309 times)

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 25689
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Could somebody check my logs and see if there any problems please
« Reply #30 on: September 20, 2012, 05:43:10 PM »

It would be interesting to known whether the TO was working in the POTS PCP or the FTTC. If it was the latter, then he would have to be a BT Operate TO.
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

Ronski

  • Helpful
  • Kitizen
  • *
  • Posts: 3106
Re: Could somebody check my logs and see if there any problems please
« Reply #31 on: September 20, 2012, 05:50:31 PM »

He said he was working on the DSLAM, so I presume the FTTC cabinet.

Run the measurements lab test again:

Code: [Select]
Your system: Windows 7 version 6.1
Java version: 1.7.0_07 (x86)

TCP receive window: 188760 current, 261360 maximum
1.0E-6 packets lost during test
Round trip time: 22 msec (minimum), 93 msec (maximum), 42.41 msec (average)
Jitter: 71 msec
0 seconds spend waiting following a timeout
TCP time-out counter: 234
0 selective acknowledgement packets received

No duplex mismatch condition was detected.
The test did not detect a cable fault.
No network congestion was detected.
No network address translation appliance was detected.

0.0289% of the time was not spent in a receiver limited or sender limited state.
96.55% of the time the connection is limited by the client machine's receive buffer.
Optimal receive buffer: 267632640 bytes
0 duplicate ACKs set

Code: [Select]
WEB100 Kernel Variables: Client: localhost/127.0.0.1 CurMSS: 1452 X_Rcvbuf: 87380 X_Sndbuf: 676216 AckPktsIn: 16685 AckPktsOut: 0 BytesRetrans: 0 CongAvoid: 0 CongestionOverCount: 0 CongestionSignals: 0 CountRTT: 16660 CurCwnd: 262812 CurRTO: 234 CurRwinRcvd: 188760 CurRwinSent: 5888 CurSsthresh: 2147483647 DSACKDups: 0 DataBytesIn: 0 DataBytesOut: 49420416 DataPktsIn: 0 DataPktsOut: 33577 DupAcksIn: 0 ECNEnabled: 0 FastRetran: 0 MaxCwnd: 262812 MaxMSS: 1452 MaxRTO: 282 MaxRTT: 93 MaxRwinRcvd: 261360 MaxRwinSent: 5888 MaxSsthresh: 0 MinMSS: 1452 MinRTO: 223 MinRTT: 22 MinRwinRcvd: 28468 MinRwinSent: 5840 NagleEnabled: 1 OtherReductions: 0 PktsIn: 16685 PktsOut: 33577 PktsRetrans: 0 RcvWinScale: 7 SACKEnabled: 3 SACKsRcvd: 0 SendStall: 0 SlowStart: 179 SampleRTT: 34 SmoothedRTT: 34 SndWinScale: 2 SndLimTimeRwin: 9735749 SndLimTimeCwnd: 291426 SndLimTimeSender: 56404 SndLimTransRwin: 9 SndLimTransCwnd: 20 SndLimTransSender: 12 SndLimBytesRwin: 48611328 SndLimBytesCwnd: 755136 SndLimBytesSender: 53952 SubsequentTimeouts: 0 SumRTT: 706551 Timeouts: 0 TimestampsEnabled: 0 WinScaleRcvd: 2 WinScaleSent: 7 DupAcksOut: 0 StartTimeUsec: 216886 Duration: 10083665 c2sData: 3 c2sAck: 3 s2cData: 8 s2cAck: 5 half_duplex: 0 link: 100 congestion: 0 bad_cable: 0 mismatch: 0 spd: 39.21 bw: 261.21 loss: 0.000001000 avgrtt: 42.41 waitsec: 0.00 timesec: 10.00 order: 0.0000 rwintime: 0.9655 sendtime: 0.0056 cwndtime: 0.0289 rwin: 1.9940 swin: 5.1591 cwin: 2.0051 rttsec: 0.042410 Sndbuf: 676216 aspd: 0.00000 CWND-Limited: 444.15 minCWNDpeak: -1 maxCWNDpeak: -1 CWNDpeaks: -1 The theoretical network limit is 261.21 Mbps The NDT server has a 330.0 KByte buffer which limits the throughput to 121.64 Mbps Your PC/Workstation has a 255.0 KByte buffer which limits the throughput to 47.01 Mbps The network based flow control limits the throughput to 47.27 Mbps Client Data reports link is 'Ethernet', Client Acks report link is 'Ethernet' Server Data reports link is 'OC-48', Server Acks report link is 'FastE'
« Last Edit: September 20, 2012, 05:57:10 PM by Ronski »
Logged
Formerly restrained by ECI and ali,  now surfing along at 388/21  ;D

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 25689
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Could somebody check my logs and see if there any problems please
« Reply #32 on: September 20, 2012, 07:56:49 PM »

Quote
He said he was working on the DSLAM, so I presume the FTTC cabinet.

Interesting. It could possibly have been poor terminations of the tie-pairs.  :-\

As for the results from running that Measurement Lab's Test, I am not sure what is that I should be considering.  ???
« Last Edit: September 20, 2012, 07:59:14 PM by burakkucat »
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

Bald_Eagle1

  • Helpful
  • Kitizen
  • *
  • Posts: 2720
Re: Could somebody check my logs and see if there any problems please
« Reply #33 on: September 20, 2012, 08:09:29 PM »

As for the results from running that Measurement Lab's Test, I am not sure what is that I should be considering.  ???

Me neither.
Was that a good or a bad test result, & could you please explain why?

Logged

Ronski

  • Helpful
  • Kitizen
  • *
  • Posts: 3106
Re: Could somebody check my logs and see if there any problems please
« Reply #34 on: September 20, 2012, 08:11:05 PM »

I just posted the results for SecTSys, rather than double post - I've not got any clue as to what most of them mean either.

Hopefully he'll be along to comment and explain.
Logged
Formerly restrained by ECI and ali,  now surfing along at 388/21  ;D

SecTSys

  • Member
  • **
  • Posts: 84
  • I only work with HTCPCP
    • Putney Computers Facebook page
Re: Could somebody check my logs and see if there any problems please
« Reply #35 on: September 21, 2012, 07:44:11 PM »

sorry broke my keyboard  so using  virtual  keyboard  atm

tbh i only know what i have been told to look for elsewhere but i know this
 "1.0E-6 packets lost during test" is video or voip data packets related being lost
"Jitter: 71 msec" is aweful you ought to have a line test done. - it shouldn't be more  then  2 - 3 ms max preferably 0 it indicates interference on the line possibly a line fault or a bad connection somewhere
"96.55% of the time the connection is limited by the client machine's receive buffer." indicates your computer buffer on the computer needs to be optimized

there is a lot that i do know on this but for detailed descriptions look here

the links are:
http://testmy.net/ipb/topic/8964-ndt-test-definitions-part-1/page__hl__%2Bndt
http://testmy.net/ipb/topic/8965-ndt-test-definitions-part-2/



Logged
Visit the Live Gaming Website STSLG Website
Visit my YouTube gaming channel at STS Live Gaming

Ronski

  • Helpful
  • Kitizen
  • *
  • Posts: 3106
Re: Could somebody check my logs and see if there any problems please
« Reply #36 on: September 23, 2012, 10:17:24 AM »

Had another strange thing this morning, the modem appeared to have crashed about 7am, couldn't access it via the IP and it wasn't showing in the routers attached devices, TBB ping graph shows 100% packet loss 7am until I rebooted it.
Logged
Formerly restrained by ECI and ali,  now surfing along at 388/21  ;D

SecTSys

  • Member
  • **
  • Posts: 84
  • I only work with HTCPCP
    • Putney Computers Facebook page
Re: Could somebody check my logs and see if there any problems please
« Reply #37 on: September 26, 2012, 01:09:21 AM »

Personally - i would reset the Router back to factory defaults then restart the hacking process if yours has been broken into by yourself!!
Logged
Visit the Live Gaming Website STSLG Website
Visit my YouTube gaming channel at STS Live Gaming

Ronski

  • Helpful
  • Kitizen
  • *
  • Posts: 3106
Re: Could somebody check my logs and see if there any problems please
« Reply #38 on: September 26, 2012, 10:24:18 AM »

if yours has been broken into by yourself!!

Now I am confused, what do you mean?
Logged
Formerly restrained by ECI and ali,  now surfing along at 388/21  ;D

Ronski

  • Helpful
  • Kitizen
  • *
  • Posts: 3106
Re: Could somebody check my logs and see if there any problems please
« Reply #39 on: September 27, 2012, 03:39:02 PM »

I've just been comparing my current stats to the somebody else's graphs who has estimated he's about 600 meters from his cabinet

I've notice that in the bit loading graph and the SNR graph my graphs have the blocks missing above 2750Khz, why is this?

I presume from the bit loading graph that my connection is not using the highest band at all, and this is why my DS rates are a lot lower even though I'm about 450 meters, where as he estimates 600 meters.

Also his first and second red blocks both look stronger.

My latest current stats

Also, yesterday my SNR fluctuated quite a bit, which dropped the attainable rate. Yesterdays graphs

The connection does seem to be holding sync now, not had any resyncs since the engineers visit, except the one on Sunday where I had to reboot the modem, although come to think of it there was one about 6am on Sunday - just before it appeared to crash/lock up.
Logged
Formerly restrained by ECI and ali,  now surfing along at 388/21  ;D

Bald_Eagle1

  • Helpful
  • Kitizen
  • *
  • Posts: 2720
Re: Could somebody check my logs and see if there any problems please
« Reply #40 on: September 27, 2012, 06:51:15 PM »


I've notice that in the bit loading graph and the SNR graph my graphs have the blocks missing above 2750Khz, why is this?

I presume from the bit loading graph that my connection is not using the highest band at all, and this is why my DS rates are a lot lower even though I'm about 450 meters, where as he estimates 600 meters.


I think you meant from TONE 2750 onward (roughly 12MHz).

Yes, your presumption is correct.
You are connected to an ECI DSLAM whereas the other user is connected to a Huawei DSLAM.
This is confirmed by the Discovery & Medley band plan tones in pbParams.

We can indeed see that your connection "Discovers" all the tone bands, but at "Medley Phase" (actual connection in use), the higher DS tone band is not used.

Code: [Select]
Discovery Phase (Initial) Band Plan
US: (0,95) (880,1195) (1984,2771)
DS: (32,859) (1216,1959) (2792,4083)
Medley Phase (Final) Band Plan
US: (0,95) (880,1195) (1984,2771)
DS: (32,859) (1216,1959) -----------------------------------> Higher frequency tones 2792 to 4083 not used
          VDSL Port Details       Upstream        Downstream
Attainable Net Data Rate:      11311 kbps         48296 kbps
Actual Aggregate Tx Power:        6.8 dBm          11.1 dBm
============================================================================
  VDSL Band Status        U0      U1      U2      U3      D1      D2      D3
  Line Attenuation(dB): 2.0 33.0 50.9   N/A 16.3 43.0 64.9
Signal Attenuation(dB): 2.0 32.9 50.5   N/A 16.3 43.0   N/A
        SNR Margin(dB): 6.6 6.5 7.3   N/A 4.1 4.1   N/A
         TX Power(dBm): -4.5 -8.8 6.2   N/A 8.7 7.3   N/A

That is also confirmed by N/A being reported in the D3 band section


Quote
Also his first and second red blocks both look stronger.

My latest current stats

Also, yesterday my SNR fluctuated quite a bit, which dropped the attainable rate. Yesterdays graphs

The connection does seem to be holding sync now, not had any resyncs since the engineers visit, except the one on Sunday where I had to reboot the modem, although come to think of it there was one about 6am on Sunday - just before it appeared to crash/lock up.

Your DS SNRM graph looks rather "unusual" - any idea what might be causing that?

Also your DS RSCorr errors look high.
However, that does appear to be a typical phenomenon from a Huawei HG612 connected to an ECI DSLAM.
As soon as as an unlocked ECI modem on an ECI DSLAM can be reliably monitored & graphed, we will know if it is just a slight incompatibility issue, or a general ECI DSLAM issue.

I can't recall now, but does your connection ever report GREEN US data in the QLN, SNR & Hlog graphs as occasionally seen for other ECI DSLAM connections?

Logged

Ronski

  • Helpful
  • Kitizen
  • *
  • Posts: 3106
Re: Could somebody check my logs and see if there any problems please
« Reply #41 on: September 28, 2012, 08:26:17 AM »

Your DS SNRM graph looks rather "unusual" - any idea what might be causing that?

Thanks Paul, if your reffering to the SNRM graph which shows both US & DS, where the DS changes from 6 to about 4 at around 9am I have no idea, presume this must be electrical interference of some kind (but perhaps not - see below). The DS SNRM graph is blank for some reason.



Quote
I can't recall now, but does your connection ever report GREEN US data in the QLN, SNR & Hlog graphs as occasionally seen for other ECI DSLAM connections?

Yes, sometimes. I ran a current stats at 18:19 yesterday and that one shows the green US data, some of the others do to, but not all of them.

I purchased a 450mm CAT6 RJ11 cable from Mr..Telephone on ebay and fitted that yesterday at 18:00. The SNRM seems to have returned to 6 - this would suggest that either the cable cured the cause of the noise or I think more likly that the modem resyncing cured it. Attainable speed increased slightly, sync speed dropped slightly and attenuation dropped slightly too. DS_RSCorr dropped right off to at 18:00.

Link to graphs

PS. I've disabled the emails in the getstats scripts, I was getting far to many and can't see that anything was slowing my server down.

PPS. Is it unusual for the D3 block to be unused on a 450 meter line length?
« Last Edit: September 28, 2012, 08:41:20 AM by Ronski »
Logged
Formerly restrained by ECI and ali,  now surfing along at 388/21  ;D

Bald_Eagle1

  • Helpful
  • Kitizen
  • *
  • Posts: 2720
Re: Could somebody check my logs and see if there any problems please
« Reply #42 on: September 28, 2012, 08:55:30 AM »


Thanks Paul, if your reffering to the SNRM graph which shows both US & DS, where the DS changes from 6 to about 4 at around 9am I have no idea, presume this must be electrical interference of some kind (but perhaps not - see below).


Yep, that's the one.

Quote

The DS SNRM graph is blank for some reason.


The data for the blank graphs isn't harvested & sorted by the script version.
It will be part of the next release (an .EXE program that works much quicker & more reliably - when I can find time to get it finished properly)

Quote

I purchased a 450mm CAT6 RJ11 cable from Mr..Telephone on ebay and fitted that yesterday at 18:00. The SNRM seems to have returned to 6 - this would suggest that either the cable cured the cause of the noise or I think more likly that the modem resyncing cured it. Attainable speed increased slightly, sync speed dropped slightly and attenuation dropped slightly too. DS_RSCorr dropped right off to at 18:00.


Let's hope that's a permanent improvement.
There is an issue with RSCorr reporting from HG612 modems on ECI DSLAM connections.
The script version stops calculating delta data as the integer batch file calculation limit is reached.
Once the modem "zeros" RSCorr data (which it eventually does) the batch file starts calculating again.
The .EXE program version deals with that & continues to calculate right up to the limit.


Quote
PS. I've disabled the emails in the getstats scripts, I was getting far to many and can't see that anything was slowing my server down.

Haha. I thought you might get fed up of that soon. It was really intended more as a debugging tool, but I'm now concentrating on the program version rather than further developing the script version. :)
Logged

Ixel

  • Kitizen
  • ****
  • Posts: 1087
Re: Could somebody check my logs and see if there any problems please
« Reply #43 on: September 28, 2012, 02:44:17 PM »

The ECI DSLAM's RSCorr (which I believe is also FEC?, if not then the following is irrelevant..) reporting is also odd with my Fritz!Box 7390, starting off with a small amount of FEC errors then eventually rising up into the tens of thousands per minute range and averaging there until a resync.

EDIT: FEC errors on the FB 7390 seem like RSCorr on the HG612 at the very least.

Slightly off-topic:
Briefly, from my testing of adjusting the SNRM target and capping the sync rates on the modem I discovered that DLM adjusted (lowered) the maximum and minimum on the DSLAM eventually, though these changes weren't permanent (as once I restored the FB 7390 to default settings a few days later the DLM began restoring the min/max on the DSLAM). If there's anything I've learnt I would say that one must avoid disrupting the connection to the DSLAM as there's a good chance it'll begin reducing interleaving and banding if the connection remains active for several days. Forced DLM resyncs early in the morning I don't believe get counted as a loss of sync by DLM, as I've had a DLM change follow 24 hours after a previous change (increase in speed and reduction in INP).
Logged

Bald_Eagle1

  • Helpful
  • Kitizen
  • *
  • Posts: 2720
Re: Could somebody check my logs and see if there any problems please
« Reply #44 on: September 28, 2012, 04:48:47 PM »

The ECI DSLAM's RSCorr (which I believe is also FEC?, if not then the following is irrelevant..) reporting is also odd with my Fritz!Box 7390, starting off with a small amount of FEC errors then eventually rising up into the tens of thousands per minute range and averaging there until a resync.

EDIT: FEC errors on the FB 7390 seem like RSCorr on the HG612 at the very least.


The HG612 reports FEC & CRC errors incorrectly in its GUI.
The original graphing scripts do show that discrepancy, mentioning that the data is from the GUI.

To avoid any potential confusion, the new EXE version (not ready for release yet) only reports data from xdslcmd info --stats.
FWIW, FEC & RSCorr data is identical (as expected).

What would be interesting to see would be the equivalent data obtained from an unlocked ECI modem connected to an ECI DSLAM.
Maybe RSCorr/FEC would not then appear excessive due to being compatible?

I suppose the main question is, do these high RSCorr counts actually degrade throughput and/or affect DLM's decision making or not?

If not, they could be simply ignored as a "feature".

Example of RSCorr from another HG612 on an ECI DSLAM connection is attached for reference (data obtained via the under test .EXE version).

« Last Edit: September 28, 2012, 04:53:22 PM by Bald_Eagle1 »
Logged
Pages: 1 2 [3] 4 5 ... 7