I’m testing an old etinc pcisync/2 card I had onhand in a junker pc using the ‘demo’ key. I’ve got a T1 routing through it now but I can’t seem to get the queue settings to work. Are the queue settings locked-out in demo mode?
Changing the synchronous-default type didn’t change performance at all. I made sure the mtsync1 interface was set to synchronous-default..
It looks perfect otherwise. If the queue management will work, I’ll be buying another license…
demo should be limited to one queue rule.
for testing better use 24hour trial period.
err, sorry, I am using the 24 hour key… Oops 
24hour key has no limitations but 24 hour limit, otherwise this is fully functional
Hmm, then the queue settings did not make any changes to the ping (56 byte) times when uploading (1500 byte packets, at full line rate) over the connection… Very weird. I’ll investigate more in the morning (2AM here)
ping times? this is not a way of testing. try making a simple queue for web traffic (port 80) and try to download something. then stop download, disable the queue and try to download again.
[admin@MikroTik] queue simple> add name=Limit-Local interface=Local target-address=192.168.0.0/24 max-limit=65536/131072
a simple queue rule, which will limit the download traffic to 128Kib/s and upload to 64Kib/s for clients on the network 192.168.0.0/24, served by the interface Local
No, ideas for ‘DEMO’ key Mikrotik is too many arguments for true and easy ways,…
Peace all
BalimoreDOTcom
Well, that’d be an IP queue. I need to set an interface queue to keep. With my old cisco, the choices are basically fifo (pfifo), red, and fair-queue (sfq).
On the Cisco, setting the interface to fifo (“no fair-queue”/“no random-early-detection”) will give me the same performance I’m getting now. I upload, all services get lagged 150-250ms. enabling sfq or red will keep the rtt times under 40 ms typically when effectively maxing (98%+) out the line.
I know when using MT as a PPPoE or PPTP server, the interface queue setting works (pcq is quite awesome in this situation), but its just not working for this.
The reason I don’t want to use the ip-based queue is I’d have to undershoot the line rate by at least 15% to ensure the interface’s “unmanaged” tx queue didn’t fill up.
So my reply last night didn’t make a whole lot of sense… I’ll attempt to explain better…
When dealing with PPP across a sync serial interface you get about as much delivery ‘predictability’ as a full-duplex ethernet port, except at a considerably lower (in this case 1536kbit) speed. Theres no flow control involved like conventional serial lines, and the speed always stays the same. Its speed is dictated by a timing sync signal sent by the telco.
From the way it appears, there is aproximately a 20 packet PFIFO (packets sent in order initially processed) buffer on the sync ppp interface.
For simplicity’s sake, we’ll say a 1536Kbit T1 moves 190KBytes/sec…
20 packet buffer @ 1500 bytes/each = 35KB… 35/190 = 0.1578 = 157 ms of potential lag in the transmit data path…
Your proposal is for me to put a ‘slower’ queue in front of the interface’s buffer. This would ‘kinda’ work under normal circumstances with a significant loss of performance (I’d have to set it around 1.2-1.3mbit to ensure the interface buffer never had a chance to fill up). It’d be much more efficient to manage the interface’s buffer itself…
I do know some of linux’s interface drivers don’t have hooks for queue management and the DSCC4 driver may be this way, I haven’t checked yet.
[eugene@SM_BGP] > /queue interface print
0 ether1 ethernet-default
1 ether2 ethernet-default
2 default
[eugene@SM_BGP] > /queue type print
0 name="default" kind=pfifo pfifo-limit=50
1 name="ethernet-default" kind=pfifo pfifo-limit=50
2 name="wireless-default" kind=sfq sfq-perturb=5 sfq-allot=1514
3 name="synchronous-default" kind=red red-limit=60 red-min-threshold=10 red-max-threshold=50 red-burst=20 red-avg-packet=1000
4 name="hotspot-default" kind=sfq sfq-perturb=5 sfq-allot=1514
5 name="default-small" kind=pfifo pfifo-limit=10
[eugene@SM_BGP] >