I have a RB450G that is in-front of a collocated web server that mainly streams videos from a website, it averages 30-60MBIT 24/7.

It also does nat Masquerading (as i have the server on a private IP ) and 3 DST-NAT Netmap rules (port 80, 443, video port) thats about it as far as rules.

the cpu usage (i monitor via snmp) never goes above 40-50% and is generally at 15-20% most of the time.

however on the port going to the server im seeing about 5-10k RX drops a day and on the uplink (public IP) eth port im seeing about 3k RX drops a day. no other errors, and neither side (SWITCH or my server ifconfig) reports any errors or RX drops.

Ive also tried setting the CPU to 800mhz from 680 and it didn't really seem to help (still saw RX drops). it did succesffuly change after reboot as verified by system->resources

free ram is always above 200mb

any ideas? is it just that i need to upgrade to a fast ROUTER board like that new 1100? its just not really that much BW

edit: TX packets /sec is usually 2000-5500 p/s (this server is only upstream so that is why ive not given any incoming numbers really)

first you can try to reduce the port speeds to 100Mbps, especially the one towards your PC.
the problem can be that traffic from the PC via gigabit ethernet arrives as bursts, i.e. many packets at a full 1Gbps, then for a while nothing, then again a series of packets back-to-back at 1Gbps etc. specifically packet loss can occur if the PC Ethernet controller's TX ring size is larger than the mikrotik ethernet controller's RX ring size, and if Pause is not used (which is not i understand): then the ethernet hardware on the PC has enough packets in its TX ring to completely flood the mikrotik router beyond what the mikrotik RX ring can hold. or the same in other words: the reason for packet loss may be not your *average* packet rate, but the peak packet rate, which can be a full 1Gbps. reducing to 100Mbps should help smooth things a bit.
another measure to reduce the burstyness of the traffic could be, for a linux server, to increase the timer frequency. in the old days the timer would run at 100Hz: the application would wake up every 10ms, and then deliver all the packets that it has to (which tends to generate bursts). if the same is done at 1000Hz, the packets flow more evenly. making the kernel preemptable has a similar effect: it reduces the latency for your server application, and as a result it happens less often that the server application has to "catch up" and deliver a lot of packets as a burst. in that sense it can also help to have more cores on the server, just to be more likely to have a core available to run your application (i.e. it is again not about being able to handle average loads).

the second thing to consider is the hardware of the RB450G: from what i've seen, one is directly connected to the atheros controller, while the other ports go though a switch and effectively share a single 1Gbps port at the controller. that should not be an issue at your data rates, but again, the problem is not about average data rates (or CPU load, in your case) but merely about what happens in the moment when packets get lost.

does anyone know the RX and TX ring sizes and whether Pause is supported for RG450G and RB750G ??

andy

Hi,

thanks for the reply, I made the settings after your post (set both ports to 100mibt ), and now about 15 hours later im still seeing the RX drops on both interfaces.

another point that is unusual is its ONLY RX drops, not TX. On the port to the server its the RX that gets all the activity, on the up-link to the internet port its the TX that gets all the activity, either way its ONLY RX drops that show up, no TX drops.

i have also emailed mikrotik support last week about this and never received a reply so i came here.

EDIT:

the second thing to consider is the hardware of the RB450G: from what i've seen, one is directly connected to the atheros controller, while the other ports go though a switch and effectively share a single 1Gbps port at the controller. that should not be an issue at your data rates, but again, the problem is not about average data rates (or CPU load, in your case) but merely about what happens in the moment when packets get lost.

re quote above: The two ports with all the activty are eth 2 and 4, so there maybe something to this as i would assume port 1 is tied to the CPU as you suggest, Can MIKROTIK WEIGHT IN HERE prehaps?

any other ideas?

thanks

when you reduce to 100Mbps, has the probability of RX drop (i.e. how man drops per million packets received, ppm) changed?? what is the drop rate?

another possible issue could be that the kernel is busy (blocked) and temporarily can not process packets.
one candidate is Flash writes: can you see increased packet loss (counting up) when you copy a file to the router's flash memory?? or do you use L2TP encrypted tunnels or the like (the encryption causing latency)?

i manage a customer's video network, with two 2800 cisco routers, one RB750G and one MT X86 under vmware. one of the video systems provides exact packet loss data. when i cause OSPF to take the path through the cisco's, there is no loss for many hours. through the MT routers, i can see the lost packet counter go up -- the loss is a fairly constant 50ppm.
i suspected VMware, and am about to replace it with a second RB750G next week. we'll see...

andy

this is resolved somewhat:

first when i tried the option above of setting the port to 100mbit, the status showed 100mbit, even through router restarts.

I had the datacenter change the cables, and ports on the 450G...same problems with RX drops.

I then tried to set the port (going to the server) to 100mbit, but it stayed at 1GBIT this time (via status).. so i then turned off auto negotiation, then status showed 100mbit...and since then NO DROPS.

I will update this to confirm in a few days, but so far 36 hours and no drops, before i would get them in 1 hr.

CONFIRMED FIXED, no more RX DROPS (never had any TX drops from start) so no drops at all now.

nice!

glad it helped. yep -- it can be irrational to reduce the speed of an interface to eliminate packet drops --- normally we try to increase speeds to fix such a problem.

but that's how it is when the RX ring is too small. i'd still be interested to learn from MT the RX buffer sizes for RB450/750G and x86 PCnet32 ethernet controllers. (not to mention to be able to change/increase it)

... or do i have to order the open source CD from MT to learn these two parameters????
andy

Try Increasing
Queues-> Queue Types-> ethernet-default

Try Increasing
Queues-> Queue Types-> ethernet-default

did you change the above as well? anybody know how increasing this helps?