есть несколько подсетей:

192.168.1.0
192.168.2.0
192.168.3.0

необходимо настроить delay_pools так, чтобы для 1-й подсети 512 Кбит/с, 2-й 256 КБит/с,
3-й 128КБит/с, . Я вот примерно набросал...Насколько я понимаю судя по определению ("class 2 a class 2 delay pool contains one unified bucket and 255 buckets, one for each host on an 8-bit network (IPv4 class C)")
мне нужно исп-ть класс 2 для работы с подсетями класса С. Подскажите плз если есть недочёты....

acl subnet1 src 192.168.1.0/24
acl subnet2 src 192.168.2.0/24
acl subnet3 src 192.168.3.0/24

delay_pools 3
delay_class 1 2
delay_parameters 1 64000/64000 64000/64000 -1/-1
delay_access 1 allow subnet1
delay_access 1 deny all

delay_class 2 2
delay_parameters 2 32000/32000 32000/32000 -1/-1
delay_access 2 allow subnet2
delay_access 2 deny all

delay_class 3 2
delay_parameters 3 16000/16000 16000/16000 -1/-1
delay_access 3 allow  subnet3
delay_access 3 deny all

и ещё плз объясните как лучше в реальной работе указывать
delay_parameters 3 16000/16000 16000/16000 -1/-1
или
delay_parameters 3 16000/16000 -1/-1 4000/4000 например...
чтобы у конечного хоста было фиксированное ограничение или -1/-1?

• подсети и delay_pools,ipmanyak, 07:52 , 02-Июл-10
  • подсети и delay_pools,DeadLoco, 03:23 , 18-Июл-10
• подсети и delay_pools,ipmanyak, 07:59 , 02-Июл-10
  • подсети и delay_pools,ll75, 09:26 , 02-Июл-10

>[оверквотинг удален]
>delay_parameters 3 16000/16000 16000/16000 -1/-1
>delay_access 3 allow  subnet3
>delay_access 3 deny all
>
>
>и ещё плз объясните как лучше в реальной работе указывать
>delay_parameters 3 16000/16000 16000/16000 -1/-1
>или
>delay_parameters 3 16000/16000 -1/-1 4000/4000 например...
>чтобы у конечного хоста было фиксированное ограничение или -1/-1?

вы испльзуете пулл класса 2, а задаете в delay_parameters три параметра. Правильно так
delay_parameters 1 64000/64000 64000/64000  
delay_access 1 allow subnet1
delay_access 1 deny all

Параметр -1/-1 лучше вообще не использовать, в противном случае сквид заберет весь канал, а ведь есть еще кроме HTTP и другие сервисы, например почта. Поэтому сквиду нужно давать 70-80% канала, а не весь.
--------------------------------------
delay_parameters 3 16000/16000 2000/4000

3-ему пулу дали канал в 16Кб/сек, а индивдуально на каждого юзверя ведерки по 4Кб, а струйка в него в 2кб !  Сначала быстро усосет 4Кб, а потом будет лить со скоростью в 2Кб/cек. Точнее быстро будет усасывать объекты размером до 4Кб (на скорости в 16Кб/сек), объекты больше 4Кб будет сосать на скорости 2Кб/сек.

>быстро усосет 4Кб, а потом будет лить со скоростью в 2Кб/cек.
>Точнее быстро будет усасывать объекты размером до 4Кб (на скорости в
>16Кб/сек), объекты больше 4Кб будет сосать на скорости 2Кб/сек.

Строго говоря, это совершенно неверно. Ну, то-есть, так написано в доках сквида, но в исходниках написано совершенно другое. Во всех примерах байт-рейт пула и объем бакета выставлены примерно одинаковыми. В этом засада, потому что внятно смысла этих величин дока сквида не объясняет.

С точки зрения реализации бакет - это просто буфер, из которого элементы выдергиваются индивидами по мере надобности.  Если это индивидуальный бакет, в пуле 1-го класса, то вполне можно настраивать по примеру в конфиге. Т.е.:

delay_parameters 1 32000/32000

Но если у нас используется второй класс с агрегацией и агрегированым бакетом, то настраивать, как нарисовано в конфиге - себе дороже выйдет. Настраивать нужно примерно так:

delay_parameters 1 128000/5120000 32000/32000

Агрегированный бакет задается существенно большим, чем байт-рейт пула. В идеале он должен быть несколько больше, чем суммарный объем бакетов отдельных индивидов. Надо учитывать, что индивидуальные пулы создаются автоматически, и не всегда их количество можно заранее предугадать. Оптимально - ставить натурные эксперименты и следить за статистикой сквида, раздел "делей-пулы".

Так или иначе, нужно помнить, что размер агрегированого бакета (тотального или подсеточного - для 2 и 3 классов) должен быть БОЛЬШИМ. В некоторых тяжелых случаях - десятки мегабайт. Маленький агрегированный бакет приводит к тому, что заполняясь трафиком отдельного индивида, он тормозит потоки всех остальных пользователей, отчего появляется мультипликативный эффект постоянного затора. Чтобы поток к индивидам был плавным и гладким, агрегированные бакеты не должны заполняться полностью НИКОГДА.

юзаешь пулы класса 2, а задаешь по 3 параметра в delay_parameters! Правильно так:
>delay_class 1 2
>delay_parameters 1 64000/64000 64000/64000
>delay_access 1 allow subnet1
>delay_access 1 deny all

Параметр -1/-1 лучше вообще не юзать, иначе сквид съест вексь канал, а ведь есть еще и другие сервисы, например почта.

delay_parameters 3 16000/16000 2000/4000
3-ему пулу дали канал в 16 Кб/сек, а индивдуально на каждого юзверя ведерки по 4Кб, а струйка в него в 2Кб !  Сначала быстро усосет 4Кб, а потом будет лить со скоростью в 2Кб/cек, а  точнее - быстро будет усасывать объекты размером до 4Ккб(на скорости 16 Кб/сек) , объекты больше 4Кб будет сосать на скорости 2Кб/сек

>delay_parameters 3 16000/16000 2000/4000
>3-ему пулу дали канал в 16 Кб/сек, а индивдуально на каждого юзверя
>ведерки по 4Кб, а струйка в него в 2Кб !  
>Сначала быстро усосет 4Кб, а потом будет лить со скоростью в
>2Кб/cек, а  точнее - быстро будет усасывать объекты размером до
>4Ккб(на скорости 16 Кб/сек) , объекты больше 4Кб будет сосать на
>скорости 2Кб/сек

спс огромный за помощь, хоть прояснилось в голове немного ...