Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[broadstairs]

Thanks for that, Stuart. I'm not familiar with Wireshark, and there are a lot of unreadable characters in that file. What do you use to read it?

Sorry Eric I just assumed you would have it installed. I use Wireshark, at least for Fedora it is in the standard repositories. I believe it is available for Windows as well.

Stuart

[roseway]

I'll install it and see where that takes me.

[broadstairs]

BTW I'm now running the 32 bit windows version on W2K and that fails the 1st sample as well. I'll leave it running and see if it also fails periodically.

Stuart

[roseway]

One question, Stuart: do you have any custom commands set to run at various times? I've realised that custom commands don't work in this version, and I've fixed it now.

[broadstairs]

One question, Stuart: do you have any custom commands set to run at various times? I've realised that custom commands don't work in this version, and I've fixed it now.

Yes I do so I guess that's why I still have a problem. It gets the IP address once per hour and on start up.

Stuart

[les-70]

  All has been fine for me but I can confirm that the custom commands don't work in this version. 

One thing puzzles me, but it is nothing new, and been like it for a while although I am not sure when it first appeared.  My CRC and FEC errors plots seem to have acquired spikes/vertical lines which may be associated with some but not all standby's.  They appear over the full high of the plots but fortunately they seem to be ignored by the scaling.  A result of the scaling ignoring them is that they don't worry me much.

 Likewise I keep puzzling over whether it might be better to have errors per sample rather than per minute.   Both have interpretation issues with high sampling rates but errors per sample might be better on the graphs.

   As usual many thanks for all the tremendous work.

[roseway]

@Stuart: Yes, that would seem to be the problem. It's fixed now, so the next version should be OK.

@les-70: As you know, I've been very unsure about standby ever since you first raised it. I suspect that the reason the large spikes don't cause a rescale is that they are actually negative values being wrongly generated and displayed. If I'm right, I should be able to skip them altogether. Concerning the per-sample or per-minute question, I'll look at the possibility of making it an option.

[kitz]

Still having problems here Eric. First time I started it I got a crash List index out of bounds (I think) and now it says no data after a restart. Linux 64 bit version. It does seem to get data after a while though and it has not crashed again (yet!).

Stuart

I dont know if this info helps Eric

Ive had dslstats crash on me a few times now (I think I mentioned it in another thread somewhere).   The times it occurs is when I do a manual run on hg612 modem stats (eg do a 7day graphpd).   If dslstats is running at the time modemstats doesnt collect any data, but dslstats will just 'die'.   You wont notice that dslstats has died at first because the icon still looks ok in the system tray.   Its only later when you open dslstats that you realise there is an error message and its lost any data.

More recently its been discussed via email to BE because I thought it was perhaps only happening to me whilst I was doing rather a lot of testing for modemstats and force running the prog.  I told BE not to worry about it and Id try to ensure that for future test runs Id pause off dslstats first.

Anyhow the crux of what Im trying to say... is that perhaps its possible that dslstats crashes if another program tries to harvest stats at the same time (ie you have 2 versions running on different machines).

I'll try to see if I can force a crash again... and if so I'll attach any screen caps.

[kitz]

Ive just tried repeatedly to force a crash but cant.   However I did notice that during one of the cmds windows I briefly saw something like


*********************************
DSLstats is running - waiting

**********************************

However it flashed by so quick I couldnt see properly and it may have even said something else - maybe even HG612 stats is running.   I have deliberately have error logs turned off atm so cant find it in the logs to check. 

I think it must depend on split second timing and catching dslstats at the wrong second somewhere around 35 secs past. 

[roseway]

It is true that a crash can occur when another program tries to gather data at the same time, and this does depend on critical timing. I'm not sure if I can totally avoid it happening, but I'll have another look at it.

[rhohne]

Can any one confirm that the Target SNRM offset is actually dropping the ADSL connection as when I try it on a DG834GT the ADSL connection is not dropped

It appears that "adslctl configure --snr 100" is sent but the telnet connection is immediately terminated. Manually sending the command results in the expected disconnection.

[roseway]

You're right, it doesn't work. It will be fixed for the next version.

[NewtronStar]

You're right, it doesn't work. It will be fixed for the next version.

I do hope you can still keep the sampling rate as it is in this version after fixing stuff for the next version as I am impressed by the speed, I also have HG612_Modem_stats running in the background and have yet to see any crashes/errors in 14 hours.

Here are my specs E6700 (DualCore Intel Pentium, 3200 MHz (12 x 267)
Vista Home premium 32bit and Windows 8.1 Pro 32bit
4GB of DDR3 Ram
HG612 and BT Home Hub 3 Version 4.7.5.1.83.8.94.1.37 (Type A)

[roseway]

Yes, my plan is to base all new versions on this series. I just need to tidy up the remaining issues reported by testers.

[burakkucat]

The only thing that still "bugs" me is the legend on the y-axis of the QLN graph. 

The graph, as an entity, shows dBm versus Hz (where Hz is just an alias for Tone). The y-axis is dBm and the x-axis is Hz (alias Tone).