Sorry, forgot to paste the last policy. It is basically the same deal, just removed bandwidth statement under class-default class and added fair-queue (see below) statement. Fair-queue statement did not make any difference. I tried it with and without that statement with same result.

policy-map Small-WAN-PM

class IP-Voice-CM

priority percent 18

class IP-Video-CM

bandwidth percent 15

class Bulk-CM

set dscp af11

bandwidth percent 2

class class-default

fair-queue

Below is output for sh policy-map on test 3. I can not get output for test 1 right now as it is a production router. I did not see anything out of ordinary on it though. Bandwidth was calculated correctly, there were a couple of drops on class-default.

CLNCL-1841-WR1#sh policy-map int mu1

Multilink1

Service-policy output: Small-WAN-PM

Class-map: IP-Voice-CM (match-all)

0 packets, 0 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: dscp ef (46)

Queueing

Strict Priority

Output Queue: Conversation 264

Bandwidth 18 (%)

Bandwidth 540 (kbps) Burst 13500 (Bytes)

(pkts matched/bytes matched) 0/0

(total drops/bytes drops) 0/0

Class-map: IP-Video-CM (match-all)

0 packets, 0 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: dscp af31 (26)

Queueing

Output Queue: Conversation 265

Bandwidth 15 (%)

Bandwidth 450 (kbps)Max Threshold 64 (packets)

(pkts matched/bytes matched) 0/0

(depth/total drops/no-buffer drops) 0/0/0

Class-map: Bulk-CM (match-any)

685958 packets, 84318057 bytes

5 minute offered rate 14000 bps, drop rate 0 bps

Match: access-group name BackUp-Traffic

0 packets, 0 bytes

5 minute rate 0 bps

Match: access-group name SMS-Traffic

685958 packets, 84318057 bytes

5 minute rate 14000 bps

QoS Set

dscp af11

Packets marked 685958

Queueing

Output Queue: Conversation 266

Bandwidth 2 (%)

Bandwidth 60 (kbps)Max Threshold 64 (packets)

(pkts matched/bytes matched) 26925/11383246

(depth/total drops/no-buffer drops) 0/0/0

Class-map: class-default (match-any)

17947413 packets, 3930936868 bytes

5 minute offered rate 343000 bps, drop rate 0 bps

Match: any

Queueing

Flow Based Fair Queueing

Maximum Number of Hashed Queues 256

(total queued/total drops/no-buffer drops) 0/305/0

Test 1's class-default was FIFO and Test 3' class-default was FQ, then? In your original post you note 1.3 Mbps for Test 1 and 3 Mbps for Test 3, but in your reply post, FQ didn't make a difference and same result?

In your policy stats, Test 3(?), I see 305 recorded drops. Any of these happening during the FTP push test? What about for Test 1?

Test1 policy-map -

policy-map Small-WAN-PM

class IP-Voice-CM

priority percent 18

class IP-Video-CM

bandwidth percent 15

class Bulk-CM

set dscp af11

bandwidth percent 2

class class-default

bandwidth percent 40

Test3 policy-map -

policy-map Small-WAN-PM

class IP-Voice-CM

priority percent 18

class IP-Video-CM

bandwidth percent 15

class Bulk-CM

set dscp af11

bandwidth percent 2

class class-default

fair-queue

In test 3 also tried to remove fair-queue statement. With or without fair-queue statement the reslut is the same - around 3mbps theoughput.

with fair-queue statement Multilink int shows Queueing strategy: Class-based queueing,

without fair-queue statement Multilink int shows Queueing strategy: weighted fair

Thanks

Regarding Test #3, with and without an explicit FQ statement, although display is a bit different believe it's, more or less, still FQ. Test #1, however, with an explicit bandwidth statement uses FIFO. I.e., queuing for class-default would be different.

It's possible the performance difference is due to different queue depths provided by FQ vs. FIFO. You haven't posted enough stats to know for sure, but if one implementation seems to register more drops than the other, if it does, a different drop rate could account for the performance difference.

What outputs would you like to see? Drops count is not consistant. It is always low though.

Show policy stats at the end of each test. This also assumes, counters cleared before test and no other traffic during test.

If drop counts not consistant, is there other traffic during test?

There is other traffic on the link. I did my testing during daytime. Though, no drops on physical interface or multilink at that time. It doesn't make any sense. Why would there be any drops (total drops)on class-default if there is no congestion.

I will repeat tests tonight.

I also hooked up two 1841( with 2 T1 WICs each) back to back with T1 x-over cables to see if I can reproduce this slowness and was not able to.

Thanks

Why drops?

Individual TCP flows will "window" a set of packets at sender's interface speed. Insufficient sized router queues will drop packets if "window" larger than queue can contain. Packets drops will have TCP backoff its transmission rate.

Do I undersand correctly that you are suggesting that these drops will register only on sh policy-map int mult1 output, but not on physical interface (sh int)?

No, not suggesting that. I was just suggesting, TCP flow rates are impacted by drops. However, on the question of drops being registered on policy stats but not on the interface stats, believe they should show on both sets of stats. I don't have a ready explanation if they don't.