Пару моментов:
- где код функций stakan и geto? - проблема явно не в установке интервалов, а работе этих функций;
- я бы не хотел попасть на такой сайт, который раз в секунду будет пытаться скачать что-то откуда-то и полностью грузить канал;
- с такой периодичностью обновление часов не делается - это глупость ... есть несколько вариантов решения, но сразу встречный вопрос: чем таймер на клиентской машине хуже серверного таймера??? - понимаю, что надо быть уверенным, что клиент работает правильно с точки зрения разработчика, но решать это можно весьма просто: раз в определенное время (30-60 секунд) проверять синхронизацию, хотя даже это достаточно глупо - ни сама отсылка, ни тем более получение "сигнала" не будет равно 1 секунде - из-за однопоточности javascript. Как альтернатива, весьма эффективным решением может являеться создание сокета с сервером, где сначала проверяется его качество, скорость, задержки, вырабатывается расписание синхронизаций - либо новыми средствами html5, либо флешем;
- не знаю, не смотрел, сколько параллельных асинхронных запросов позволяет сделать ИЕ9, но у предыдущих было ограничение в 2 потока, поэтому очевидна проблема в том, что прайс не успевает так быстро сформироваться на сервере и доставиться, а уже интервалом делается следующий запрос; кстати, любой навигатор это ждет - насколько бы хорошим не был канал, но весьма очевидно, что при наличии нескльких подключенных клиентов сервер рано или поздно не будет успевать, и даже если возможных запросов будет достаточно много (как у Хрома), то они будут сами забивать канал и "мешать" друг другу, и все равно код "встанет".

Если честно, то я вообще не понимаю, чем ты руководствуешься, делая такой механизм, изначально мягко говоря не очень правильный с точки зрения рациональности и необходимости, но уверен, что ты идешь не по правильному пути. Насчет таймера сказал, а по поводу прайса - ты уверен, что клиенту он нужен раз в секунду??? - но даже если так, то почему его не пытаться обновить уже после прихода ответа от сервера? - не через setInterval, а через setTimeout.

Да, действительно, в IE7 их стало 4, а в IE8-9 - аж 6, как и у большинства других браузеров. Неплохое исследование нашел тут (второй столбец - количество конкурирующих запросов на один хост).

В любом случе - проблема так или иначе с такой частотой вылезет.
Почему работает в одних и не работает в ИЕ (кстати, мы не знаем, в какм ИЕ идет тест): думаю, дело в механизме формирования очередности - одни браузеры ждут очередности отправить запрос, другие виснут или вызывают исключение при всех занятых соединениях. Хотя в jQuery вроде какой-то пул сделан, но черт его знает, как он поведет себя при такой лавине запросов.

))) Даже для локалхоста выдача ответа "сервера" (надо полагать, "прайс" - это некий ответ сервера - текст, json, xml или другое, иначе смысл теряется вовсе), который формируется на базе загружаемого файла или БД и размером хотя бы несколько десятков килобайт - от сложности - вполне может не вложиться в секунду, даже на вполне приличной машинке.

st_stЧто-то помнится, что IE7 максимум 2 параллельных ajax-запроса держал, остальные просто в очередь становились.
Тоже так считал, но при поиске вменяемого и доверительного ресурса неоднократно попадал на упоминание, что у ИЕ6 было 2 возможных конкурентных запроса к одному хосту, а у ИЕ7 - 4. Не факт, конечно, но ...

Если ты делаешь серьезный проект, то и решение должно быть серьезным ... а аукцион (!), где люди выкладывают реальные деньги, сделанный на setInterval - это, извини, погное г..но! Более двух лет разрабатывал онлайн-мультипользовательское казино, поэтому хорошо разбираюсь в теме. Тебе надо копать в сторону как минимум Comet - Server Push, чтобы не клиент теребил сервер на предмет изменений, а сервер сам обновлял клиентов при изменении положения. Однозначно вижу сокет.

А по поводу таймера рекомендации те же: таймер на любой пользовательской машине ничем не уступает серверному, посылать надо не сам "сигнал точного времени", а только синхронизатор-перестраховщик. Ведь "час М" на сервере по окончании таймера случается не тогда, когда прийдет запрос от клиента с требованием "у меня закончилось время, я выиграл", а окончание таймера на сервере и последний бит самого последнего клиента до завершения времени. Поэтому задачу тут надо не решать "в лоб", так как даже с сокетом время сервера при отображении у клиента будет искажено из-за его удаленности, причем, клиент, у которого, скажем, стоит на закачке uTorrent, получит время последним. Абсурд? При твоем решении абсурд в квадрате. Подходи к вопросу с другой стороны - какие есть риски и как сделать работу комфортной. Баланс между ними и будет правильным решением. В зависимости от масштабности проекта, конечно, - в случае реально претендующей на аукцион фигни, но без крупных вложений - я бы решал проблему примерно так: при заходе клиента на сайт к его запросам цеплял бы время клиента и на основе десятков запросов вычислял средневзвешенное время поправки времени (при ставке делал бы это даже с таймером или вероятней через сокет), а секундомер делал бы локальным, с поправкой на задержку. Этого можно было бы не делать, если бы не специфика аукциона - каждый желающий купить пытается сделать ставку в самый-самый последний момент и тут может возникнуть 2 ситуации: а) у меня очень быстрый инет и я послал запрос за 200 млсек до окончания с пингом в 20 млсек, а конкурент - за 400 млсек с пингом в 300млсек - должен был выиграть я, но выиграл он; б) я делаю запрос на 100 млсек до окончания, а мой пинг 120 млсек - я должен был победить, но проиграл. Естественно, это не вполне объективно - на этом могут строиться схемы обмана, но суть остается такой: подобные вопросы достаточно сложны, и решать их "в лоб" категорически нельзя, надо использовать наработанный в этой сфере опыт, притягивать математику, анализ, социологию, статистику. А подобного г..на на таймерах и интервалах в инете пруд пруди ... и их удел?

P.S. Как-то при показе одной игры в моем казино (флеш, сокеты, Java) не непосредственно заказчик, а вершина всего этого "мероприятия" - большая шишка - тоже решил попробывать. Я был очень польщен похвалой за то, что, хотя ему доводилось играть очень во многих инет-казино (деньги все-таки вкладывал), но такой отзывчивости на действия партнеров по игре он не видел. Мне вдвойне приятно было за то, что диссертаций по этой теме я не защищал, все сделано было по наитию и собственному понимаю, но, естественно, после основательного штудирования инета по этому вопросу. Этот вопрос как раз касался таймеров и аналогичной работе сервера с клиентом.

Ну, понятно. Раз эмулятор и тесты, то можно и хултурку ... ))))))