Подозреваю, что 1С не SQL.
Значит, это именно тот случай, когда надо работать в терминальном доступе.
Давайте посмотрим, что можно выиграть, если подключить 5 сетевых карт.
Вариант, когда они ставятся вместо центрального коммутаторя, рассматривать не имеет смысла - все пересылки между сегментами пойдут через сервер и вчистую загубят всю работу.
Если их подключить параллельно центральному, объединить их в "команду" Intel для балансировки нагрузки мы сразу упремся в производительность жестких дисков - ведь 1Gbit это 100 мБайт, которые перекрывает только Raid ) да и то при последовательном чтении.
Значит, двух плат с лихвой хватит, даже если большая чась информации находится в кэше. Дальше -шина.
Если мать серверная, то там PCI 64. Считаем 33мгцХ64 бит - 2 Gbit. Снова две платы?
Что еще кроме потоковой производительноси при 5 платах получаем ?
Экономится одна пересылка через коммутатор.
Если, конечно, он включен в обычном режиме - Store & Fоrward, когда пакет полностью принимается коммутатором и только после этого выдается в порт назначения.
Но современные коммутаторы(по крайней мере, Cisco) работают Port Fast - после чтения заголовка(4 байта?), пакет начинает передаваться в порт назначения. Задержка 4 байта из 1512.
Оп. Вспомнилось. В одном из первых сравений гигабитных коммутаторов в "Компьютерном обозрении" упоминалось, что на гигабитных платах с обычными пакетами не удалось получить скорость выше 400 мегабит, а только пакеты Jumbo по 8 кбайт дали потоковую производительность до 800 мбит.
И снова я возвращаюсь к терминальному доступу - 90 дней его можно использовать в тестовом режиме. После очистки одной ветки реестра тестовый период начинается снова.
1С версии 6(не SQL) очень хорошо в нем работает. Ну, раза в 3, наверное.
Мы в 99 году купили сервер за 25k$ с сетевыми картами на Intel960 и кешом в 1 мбайт(на карте:). Правда, 100 мбитными. Тогда я и игрался с балансировкой нагрузки, агрегированием каналов. Для провайдера, да, это полезно. Но не для работы с софтом, базами. Здесь нужен другой подход.
IMHO
Дрим тим.
Подозреваю, что 1С не SQL.
Значит, это именно тот случай, когда надо работать в терминальном доступе.
Давайте посмотрим, что можно выиграть, если подключить 5 сетевых карт.
Вариант, когда они ставятся вместо центрального коммутаторя, рассматривать не имеет смысла - все пересылки между сегментами пойдут через сервер и вчистую загубят всю работу.
Если их подключить параллельно центральному, объединить их в "команду" Intel для балансировки нагрузки мы сразу упремся в производительность жестких дисков - ведь 1Gbit это 100 мБайт, которые перекрывает только Raid ) да и то при последовательном чтении.
Значит, двух плат с лихвой хватит, даже если большая чась информации находится в кэше. Дальше -шина.
Если мать серверная, то там PCI 64. Считаем 33мгцХ64 бит - 2 Gbit. Снова две платы?
Что еще кроме потоковой производительноси при 5 платах получаем ?
Экономится одна пересылка через коммутатор.
Если, конечно, он включен в обычном режиме - Store & Fоrward, когда пакет полностью принимается коммутатором и только после этого выдается в порт назначения.
Но современные коммутаторы(по крайней мере, Cisco) работают Port Fast - после чтения заголовка(4 байта?), пакет начинает передаваться в порт назначения. Задержка 4 байта из 1512.
Оп. Вспомнилось. В одном из первых сравений гигабитных коммутаторов в "Компьютерном обозрении" упоминалось, что на гигабитных платах с обычными пакетами не удалось получить скорость выше 400 мегабит, а только пакеты Jumbo по 8 кбайт дали потоковую производительность до 800 мбит.
И снова я возвращаюсь к терминальному доступу - 90 дней его можно использовать в тестовом режиме. После очистки одной ветки реестра тестовый период начинается снова.
1С версии 6(не SQL) очень хорошо в нем работает. Ну, раза в 3, наверное.
Мы в 99 году купили сервер за 25k$ с сетевыми картами на Intel960 и кешом в 1 мбайт(на карте:). Правда, 100 мбитными. Тогда я и игрался с балансировкой нагрузки, агрегированием каналов. Для провайдера, да, это полезно. Но не для работы с софтом, базами. Здесь нужен другой подход.
IMHO