![]() ![]() ![]() |
|
mikenzb: Whats your normal sync speeds before the tweak.
Just a bit curious thats all.
#include <std_disclaimer>
Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.
Inphinity:hio77:
i still say steam is far worse.. least origins is only doubling or there abouts.. rather than downloading 500TB/s ..
In my experience, steam only reports false speeds for extremely short periods (though of course it remains as the 'peak' speed for the session), and usually only when it's actually rebuilding a partial file from your local cache, or downloading a very small update (for example, one of the games I have recently had a 1.7MB patch, and steam seems to fail to calculate anywhere near right when total download time is <1sec). Origin just blatantly goes "LOL GUYS WE'RE GOIN REAL FAST HERE!" when it isn't, at least for me.
hio77: looks like error rate has crawled up a tad, but still looking good..
![]()
Inphinity:hio77: looks like error rate has crawled up a tad, but still looking good..
That seems like a very high rate of FEC errors to me... I know it's certainly far from the highest posted on here, but nearly 8000 errors per minute? That has to impact on the performance of the line, surely.
#include <std_disclaimer>
Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.
Inphinity:
That seems like a very high rate of FEC errors to me... I know it's certainly far from the highest posted on here, but nearly 8000 errors per minute? That has to impact on the performance of the line, surely.
stevehodge:Inphinity:
That seems like a very high rate of FEC errors to me... I know it's certainly far from the highest posted on here, but nearly 8000 errors per minute? That has to impact on the performance of the line, surely.
My understanding is that FEC errors have no impact on performance. FEC errors are errors that have been detected and corrected using the ECC data in the transmitted block so they don't require retransmission of the block. I don't know if DLM takes FEC errors into account though our experience seems to be that it doesn't.
#include <std_disclaimer>
Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.
hio77:stevehodge:
My understanding is that FEC errors have no impact on performance. FEC errors are errors that have been detected and corrected using the ECC data in the transmitted block so they don't require retransmission of the block. I don't know if DLM takes FEC errors into account though our experience seems to be that it doesn't.
exactly the way i understand it, ild assume there is a point there where the modem needs to do more calculations than its cpu can handle, and there will be a derogation though.
Inphinity:hio77:stevehodge:
My understanding is that FEC errors have no impact on performance. FEC errors are errors that have been detected and corrected using the ECC data in the transmitted block so they don't require retransmission of the block. I don't know if DLM takes FEC errors into account though our experience seems to be that it doesn't.
exactly the way i understand it, ild assume there is a point there where the modem needs to do more calculations than its cpu can handle, and there will be a derogation though.
Yup, that's the case. And yes, it's the local performance impact of error handling I'm unsure of. I have no idea what the Frtiz' capability is in terms of this. I have seen some routers (admittedly very low spec devices) get to the point where high FEC errors lead to increased CRC errors, as the CPU is under full load trying to correct the errors that packets start being dropped. Perhaps the Ftiz' can tolerate a very hgih number of these errors before it's an issue, though. And no, DLM likely won't take it into account, as the concentrator, in theory, won't see the errors (the local router will just correct the packets before forwarding them). I'd still suspect whatever is causing that many errors, though, to be having some detrimental effect.
#include <std_disclaimer>
Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.
Inphinity:hio77:stevehodge:
My understanding is that FEC errors have no impact on performance. FEC errors are errors that have been detected and corrected using the ECC data in the transmitted block so they don't require retransmission of the block. I don't know if DLM takes FEC errors into account though our experience seems to be that it doesn't.
exactly the way i understand it, ild assume there is a point there where the modem needs to do more calculations than its cpu can handle, and there will be a derogation though.
Yup, that's the case. And yes, it's the local performance impact of error handling I'm unsure of. I have no idea what the Frtiz' capability is in terms of this. I have seen some routers (admittedly very low spec devices) get to the point where high FEC errors lead to increased CRC errors, as the CPU is under full load trying to correct the errors that packets start being dropped. Perhaps the Ftiz' can tolerate a very hgih number of these errors before it's an issue, though.
Inphinity:
And no, DLM likely won't take it into account, as the concentrator, in theory, won't see the errors (the local router will just correct the packets before forwarding them). I'd still suspect whatever is causing that many errors, though, to be having some detrimental effect.
stevehodge:Inphinity:
And no, DLM likely won't take it into account, as the concentrator, in theory, won't see the errors (the local router will just correct the packets before forwarding them). I'd still suspect whatever is causing that many errors, though, to be having some detrimental effect.
It'd see FEC errors on the upstream side though.
|
![]() ![]() ![]() |