Are these uncorrected errors excessive?
Hmm, been splashing the cash eh? and I expect you mean a 2850vn 
Do you mean WDS http://www.draytek.com/user/SupportAppnotesDetail.php?ID=118 ?
Do you mean WDS http://www.draytek.com/user/SupportAppnotesDetail.php?ID=118 ?
Yes on all counts, unfortunately....it is rather pricey when all said and done, but the capability is pretty darned good and the VOIP carries on as before.
And no, I shouldn't type when in a hurry, 10x more typos than normal and that's going some.
So yes trying a 2850, with sync now approaching 20Mbps!, SNR of 2 - this bit has me nervous
and so far good throughput....except on speedtest.net where my uploads seem to have dropped back from .82 to .44, not sure if this is due to anything in particular, as the wife "enjoyed" th extra upload speed when uploading the merchandise pics for the website ...so a shame if that's changed.
and yes I was thinking of the Wireless WDS....depending on range we now get.
So, keeping an eye on this beast and see if it behaves any better...
G.
And no, I shouldn't type when in a hurry, 10x more typos than normal and that's going some.
So yes trying a 2850, with sync now approaching 20Mbps!, SNR of 2 - this bit has me nervous
and so far good throughput....except on speedtest.net where my uploads seem to have dropped back from .82 to .44, not sure if this is due to anything in particular, as the wife "enjoyed" th extra upload speed when uploading the merchandise pics for the website ...so a shame if that's changed.and yes I was thinking of the Wireless WDS....depending on range we now get.
So, keeping an eye on this beast and see if it behaves any better...
G.
You are going to like this - it seems your 2800 isn't the only thing with uncorrected errors 
Have you noticed how far away the N key is from the S key
But don't worry about it, I do it all the time, when I look at what I typed you'd think I was dyslexic
I'm especially good at putting ; instead of ' but the annoying thing is FF spell checker doesn't always find errors with [ or ] in.
Have you noticed how far away the N key is from the S key
But don't worry about it, I do it all the time, when I look at what I typed you'd think I was dyslexic
I'm especially good at putting ; instead of ' but the annoying thing is FF spell checker doesn't always find errors with [ or ] in.
"« Last Edit: Today at 22:15 by Anotherone »"
LoL
LoL
LoL
is all I can say to that! I cannot help the fact my fingers cannot type at the speed of my brain....I this amazing ability to proof read before hitting send and seeing nothing wrong.
The minute I press "send", there's thousands of 'em.......I think thats what those uncorrected errors really are, it's not my typing at all (guv)
So back to work
why's my upload halved in speed ?!? D/load speeds are no prob at all but the upload is a tad pedestrian now (no offence to pedestrians you understand) 
G.
Quote from: Anotherone FF spell checker doesn't always find errors with [ or ] in.
There's a spell checker in this thing?!? I don't think mine's working in that case. Either that or I have worn it out!
(Whoops - I typed this reply in this afternoon, and obviously forgot to hit the 'post' button then
. It looks like things might be getting sorted out anyway.Still, this is useful background info)
To follow-up on this aspect:
Quote from: grahamn Which kind of brings me onto Jelv's question as well. To my understanding one wants as much clear air between noise and data as you can, given the trade-off against throughput. To my mind, having gone from 6 on ADSL1, to 3db on ADSL2 is fine, but when it dips to 2 and even 1 at points yesterday, delays etc are apparent - which to my mind is packet resends to be corrected, due to corruption (uncorrected). So I don't (maybe wrongly) regard 2.5 db margin as necessarily good. That says to me , your data is b***** close to the noise Do please correct me if this is wrong.
It is the right thinking, theoretically, but we haven't seen enough evidence to back it up in reality, and indeed some evidence to discount it. The path of consequences is something like this...
- A drop in SNRM would normally mean that noise has gone up (rather than signal dropping down).
- This in turn would normally imply that there is more risk of interference on the received data.
- Actual interference of data would then normally lead to an increase in errors in the blocks of data being received.
- If interleaving is turned on (and the FEC process is therefore active), you'd expect to see the FEC counter increasing at a faster rate than before.
- And whatever the state of FEC, you'd expect to see the standard-error counter increasing at a faster rate (This goes under many names, CRC and HEC are common counters). If FEC is turned on, the standard error counter would normally increase at a lower rate than when FEC is turned off - but this is hard to quantify for any one line.
- When the actual error rate (standard, not FEC) starts to get too high, you'd normally see intervention by DLM - which would increase the target noise margin and/or turn on interleaving.
- An increase in the actual error rate would normally also be reflected in packet loss - visible to any higher levels within the computer (such as when transferring files, or browsing the web) . However, ICMP packets, like "ping" packets or some DNS lookup packets, will be dropped.
- A loss of ICMP "ping" packets will be visible on the TBB BQM "ping graph"
- Once packet loss becomes too high, the knock-on effect becomes " slow browsing" as failures occur in DNS requests, and in the completion of downloads of individual components (html, js and image files)
Alternatively, the other effect of a drop in SNRM would be
- The drop in SNRM is sufficient to not only cause errors in user data, but also in the framing data used to show the modem where blocks start & end
- Or it obliterates the signal entirely
- The modem detects these kinds of problems, and chooses to disconnect from the far end, and re-synchronise.
- When re-synchronising, the modems will apply the target SNRM to establish an overhead. If high noise is still present, this will result in a drop in speed.
- While resynchronising is in progress, the user's computers will see slow-loading pages, and failure to contact DNS. A single resync will take the connection out for perhaps 30 seconds.
- While disconnected & resyncing, and ping packets will be lost - and will be seen as a red spike on the TBB graphs.
- If resyncs happen *very* regularly, the user will see protracted "slow browsing" problems
- Resyncs occurring too often is another trigger for DLM to intervene, with the same symptoms as above.
In the first case, the "slow browsing" goes hand-in-hand with noticeable packet loss - which would be visible on the TBB ping graph. We don't see this.
The problem would also show as an increased error rate when the "slow browsing" event occurs. We've seen individual error count values (both high and low), but alone they are meaningless. Single values do not show us whether the error rate has increased at any particular time. So, evidence might be there, but it hasn't been shown yet - we need to see the counter values over a period of time, to see how they change over normal periods & bad periods.
In the second case, the "slow browsing" goes hand-in-hand with many disconnections. These would be visible on the TBB ping graph too, and would show low "uptime" figures in the router. Again, we've not seen this.
Both cases would trigger DLM to intervene - causing slowdowns, interleaving, higher SNR margins, and further resyncs - and we've not seen these either.
The conclusion has to be that, although you are seeing your connection run at under 3dB, it seems to be working - packets are getting through from outside, and being responded to (certainly within 5 seconds, and likely to be a lot less). RouterStats graphs look good for a 3dB margin - there is some float, but not excessive.
And yet the slowdowns still occur, so an apparent coincidence - and yet, on multiple machines at the same time. That implies the problem is somewhere common - ISP, exchange, router or LAN. Empty TBB graphs would tend to discount the ISP and exchange. And, to some extent, the router.
My ongoing investigations would include router and LAN. I'd try to check the interaction between the two PC's when a period of slowdown was experienced externally - to see how fast files could be transferred internally. I'd try a new router; borrowed if possible, even if I had to do without VoIP for a while.
Thanks for that excellent post WWW, I knew you'd come up with something, I couldn't have put it better myself - in fact I have bookmarked it. It's that good, so if it's needed again anywhere I can plagiarise it to save me doing a lot of typing
As you noted, things have moved on since this evening, so we'll know a bit more in due course.
As you noted, things have moved on since this evening, so we'll know a bit more in due course.
