https://www.peerlyst.com/posts/poc-code-for-belkin-wifi-range-extender-shows-2-tragic-things-newswatcher
:awesome: :-X
https://www.reddit.com/r/networking/comments/50nidj/how_is_this_dlink_switch_performing_better_than_a/
http://www.balkannetworks.org/
http://thundercats.wikia.com/wiki/Bolkin
Quote from: burnyd on September 06, 2016, 10:41:41 AM
https://www.reddit.com/r/networking/comments/50nidj/how_is_this_dlink_switch_performing_better_than_a/
I want to find out the ending....
Fully across why Cats behave as they do, but why is the Dlink behaving 'properly' out of the box??
I'd like to see how the buffers are allocated in the Dlink compared to the cisco. At a guess I think that the dlink probably have less buffer space in total but it's allocated differently compared to the cisco. Probably the dlink can allocate 100% (or just more than Cisco 3850) of buffers to a single port at the time it's needed, I'm just guessing.
I know from 3750 experience that the default buffer tuning isn't good for any kind of bursty traffic. I think we're comparing apples to oranges here. What needs to be remembered is that if anyone suggests an access switch for anything but access-type traffic then they can't expect it to work "out the box".
Someone on that thread posted a good update:
Quote
Those switches are access switches and not designed for this kind of application but simple mass scale desktop web access etc. They have quite shallow buffers by default but can be made to behave at least unlike their lesser predecessors which could not.
Google for catalyst 3000 microburst buffer QoS and you can see for yourself this is a long standing known issue.
One of the first few links should explain how to tune the buffers far above default so you can do what you want without tail loss cratering your performance.
If we could find out exactly how the dlink was made then we could probably understand why there's less dropped packets with the dlink.
PS there's a lot of crap being posted in that link as well.
yeah but the point is: is the DLINK better? LOL
I mean are the buffers deeper without causing buffer bloat? Sure you can tune the 3850 and do proper QoS but the fact of the matter is that out of the box the dlink appears to 'behave' properly
You don't "need" QoS. I saw ppl in in that thread trying to clarify traffic. . You just enable qos to tune the buffers. All ports will be FIFO.
The dlink behaving properly is an illusion :) you'll probably find that if you swap the dlink for that cisco 3800 in a normal environment and then run that application that the reddit op is doing that you'll find problems elsewhere like regular users saying "network slow " 😅
Quote from: Dieselboy on September 08, 2016, 06:44:44 AM
You don't "need" QoS. I saw ppl in in that thread trying to clarify traffic. . You just enable qos to tune the buffers. All ports will be FIFO.
The dlink behaving properly is an illusion :) you'll probably find that if you swap the dlink for that cisco 3800 in a normal environment and then run that application that the reddit op is doing that you'll find problems elsewhere like regular users saying "network slow " 😅
True. Because you want a Belkin in there, not a Dlink.
:problem?:
http://pdfs.mhpbooks.com/Belkin.pdf
Tales of Belkin
Aleksandr Pushkin
more info here
https://en.wikipedia.org/wiki/The_Belkin_Tales
http://arstechnica.com/gaming/2016/09/the-iphone-7s-first-headphone-and-charge-dongle-isnt-coming-from-apple/
Quote from: wintermute000 on September 08, 2016, 07:15:14 PM
http://arstechnica.com/gaming/2016/09/the-iphone-7s-first-headphone-and-charge-dongle-isnt-coming-from-apple/
Belkin to the rescue!
:steamtroll: