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...
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.
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
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.Code: Select all
[admin@MikroTik] queue simple> add name=Limit-Local interface=Local target-address=192.168.0.0/24 max-limit=65536/131072
24hour key has no limitations but 24 hour limit, otherwise this is fully functional
-----------------------------------------------------------------------------------
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.
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.
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
# INTERFACE QUEUE
0 ether1 ethernet-default
1 ether2 ethernet-default
2 <pptp-int> 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] >
# INTERFACE QUEUE
0 ether1 ethernet-default
1 ether2 ethernet-default
2 <pptp-int> 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] >