Для конкретной ситуации - конкретная конфигурация.

cl_updaterate ## - количество пакетов (согласований), посланых от сервера - клиенту за еденицу времени (секунду). Эта команда напрямую связана со скоростью соединения и имея 28.8 кбод нет смысла ставить значение больше 15 (лучше 10). Потому что поделить 2.5 кб/сек на 15 и получим небольшой размер "пакета" данных на одно согласование (маловато будет). Так что для 28.8 ставьте cl_updaterate "10" и не больше.

При соединении 28.8 Кб, cl_updaterate (1/сек) от 10* до 15

При соединении 33.6 Кб, cl_updaterate (1/сек) от 15* до 20

При соединении 48.8 Кб и более, cl_updaterate (1/сек) от 20* и более

* - Оптимальное значение

cl_cmdrate ## - количество согласований в секунду, посланных от клиента - серверу. Тут дело такое: если Ты хочешь общаться по микрофону и хочешь, чтобы другие игроки слышали твой голос, а не "дизельный выхлоп" или хуже, то ставь значение 30. Но как известно единовременно исходящий и входящий потоки они:как два медведя в одной берлоге, взаимоуменьшают друг друга. Так что если общаться голосом не предвидится, то ставь от 10 до 20. В принципе для 28.8 cl_updaterate "10" и cl_cmdrate "30" вполне приемлемо. На каждые три согласования со стороны клиента - одно со стороны сервера. Сойдет!

rate #### - Поток (в байтах) со стороны сервера. Вообще эта величина должна быть ниже скорости модемного соединения примерно на 20-30% (потому что исходящий поток тоже существует и, заняв все 100% пропускной способности линии, Вы себя обречете).
При соединении 28.8 Кб, rate (бит/сек) от 2000 до 2500

При соединении 28.8 Кб, rate (бит/сек) от 2000 до 2500

При соединении 33.6 Кб, rate (бит/сек) от 2500 до 3000

При соединении 48.8 Кб и более, rate (бит/сек) от 3000 и выше

Если задать значение больше допустимого - лови FlushEntityPacket, сервер закидает тебя "пакетами" по твоему же требованию в удобный для него момент. Учтите, что для большого числа игроков (16-20) скорость соединения играет большую роль. Не рекомендуется ставить максимальное значение, если пакеты часто не доходят: на их "перепосылку" надо иметь "резерв".

cl_latency -### - Компенсация лагов. Величина, необходимая для хоть какого-то скрашивания серых будней "модемного" игрока. Задаётся как 50% или 75% от текущего пинга с противоположным знаком (100% имеет эффект, но не стОит столько задавать). Например для пинга 200 подойдет cl_latency "-150". Эта величина ОЧЕНЬ важна. Но в КС1.6 она не используется.

cl_rate #### - Тоже, что и rate, но со стороны клиента. Величина не столь важная, т.к. клиент никогда не сможет использовать её на 100% (только когда происходит закачка "лого" на сервер). По умолчанию стоит cl_rate "9999", так и оставим.

fps_max ### - Как уже видно из названия - максимальный FPS в игре. Обычно ставят 100. Это зависит от "мощности" машины. В принципе от 60 до 100 - вполне приемлемое качество. НО, без следующей переменной вы не увидите эти FPS вообще.

fps_modem ### - А вот это то, что надо. Приравниваем fps_modem к fps_max и всё. Ходит мнение, что fps_modem должна ровняться cl_updaterate. Представляете "дурдом" в 20 FPS? Я из принципа fps_max "100" и fps_modem "100" поставлю. К тому же без высокого значения fps_modem нельзя проделать кое-какие "грязные" трюки. Но у этих переменных есть и МИНУСЫ. "Лагает" сильнее, т.е. чаще при высоком fps_modem, чем при низком. Так что ставьте от 60 до 100.

В принципе - это всё, что нужно для оптимизации игры по модему. Добавлю, что при сетевой игре происходит непрерывное согласование сервера и клиента. Их пакеты взаимосвязаны и если пакеты сервера не дошли до клиента, то и пакеты клиента не будут восприниматься сервером немедленно, а встанут в очередь. Ведь пропустить ничего нельзя.

Напоследок приведу стандартный "конфиг" для скорости соединения 33.6 кбит/сек.

cl_updaterate "15"
cl_cmdrate "30"
rate "2500"
fps_max "60"
fps_modem "60"

А в autoexec.cfg неплохо бы добавить:
//При latency или пинге в 200мс
cl_latency "-150"
//Использование MMX. Не известно правда, что дает smile
r_mmx "1"
//Для того, чтобы голос свой слышать наряду с другими игроками.
voice_loopback "1"