Вот узнал про девайсы:
http://www.apt-reducer.ru/Peribit/perisphere.htmlПотом узнал про цену этих девайсов ...:)
Может кто знает про софтовые реализации подобных вкусностей ?
vtun при создании туннеля может жать трафик
>vtun при создании туннеля может жать трафикЭто совсем не то. Речь идет о замене повторяющихся блоков информации на специальные сигнатуры. Например прокачиваем повторно файл размером в гиг, а эта зараза заменяет его (файл) на пару-тройку байтов на каждый блок и железка на другой стороне востанавливает эти блоки.
>>vtun при создании туннеля может жать трафик
>
>Это совсем не то. Речь идет о замене повторяющихся блоков информации на
>специальные сигнатуры. Например прокачиваем повторно файл размером в гиг, а эта
>зараза заменяет его (файл) на пару-тройку байтов на каждый блок и
>железка на другой стороне востанавливает эти блоки.максимум что можно предложить ppp with deflate over tcp/udp
>>vtun при создании туннеля может жать трафик
>
>Это совсем не то. Речь идет о замене повторяющихся блоков информации на
>специальные сигнатуры. Например прокачиваем повторно файл размером в гиг, а эта
>зараза заменяет его (файл) на пару-тройку байтов на каждый блок и
>железка на другой стороне востанавливает эти блоки.если не ошибаюсь - FTAM ;-)
только вот opensource реализаций у него нет
>если не ошибаюсь - FTAM ;-)
>только вот opensource реализаций у него нет
Если Вам не трудно - ссылочку киньте.
Все, сам отаскал.
Мне кажется - это тоже не совсем то, что нужно.
Мы говорим о сжатии информации по крайней мере не 3-м сетевом уровне,
а FTAM в основном под передачу файлов заточен... Или я ошибаюсь ?
>Все, сам отаскал.
>Мне кажется - это тоже не совсем то, что нужно.
>Мы говорим о сжатии информации по крайней мере не 3-м сетевом уровне,
если НА 3-м сетевом уровне (на уровне IP)-то только независимая компрессия передаваемых пакетов, что и делается в разных туннелях/VPN
о кешировании файлов можно говорить только применительно к FTP/HTPP и проч.что и делается в squid`е и сетевых файловых системах.
Химеры, которые пытаются реализовывать файловый кеш на уровне IP - от лукавого ;-)
>а FTAM в основном под передачу файлов заточен... Или я ошибаюсь ?
>
нет, не ошибаетесь - FTAM - File Transfer Access and Managment ;-)
вообщем FTP+NFS+cache+...
>если НА 3-м сетевом уровне (на уровне IP)-то только независимая компрессия передаваемых
>пакетов, что и делается в разных туннелях/VPN
>о кешировании файлов можно говорить только применительно к FTP/HTPP и проч.что и
>делается в squid`е и сетевых файловых системах.
>Химеры, которые пытаются реализовывать файловый кеш на уровне IP - от лукавогоVTUN например сжимает трафик используя zlib или lzo. А данное оборудование ужимает трафик а-ля MPEG, т.е. повторяющиеся "фреймы" складываются в словарь и заменяются при передаче на ключи. Например (со слов представителя фирмы поставляющей девайсы) трафик Oracle сжимается минимум в 4 (четыре) раза. Для некоторых протоколов приводится цифра в 10 раз. Так, что это актуально не только для передачи файлов.
>VTUN например сжимает трафик используя zlib или lzo. А данное оборудование ужимает
>трафик а-ля MPEG, т.е. повторяющиеся "фреймы" складываются в словарь и заменяются
>при передаче на ключи. Например (со слов представителя фирмы поставляющей девайсы)
>трафик Oracle сжимается минимум в 4 (четыре) раза. Для некоторых протоколов
>приводится цифра в 10 раз. Так, что это актуально не только
>для передачи файлов.
Нафиг тогда это оборудование... ей-ей... Задержки, неактуальность информации... И за такие деньги лучше канал расширить.
>Нафиг тогда это оборудование... ей-ей... Задержки, неактуальность информации... И за такие деньги
>лучше канал расширить.Вот - золотые слова. А софтовой альтернативы стало-быть нет ? :)
>>Нафиг тогда это оборудование... ей-ей... Задержки, неактуальность информации... И за такие деньги
>>лучше канал расширить.
>
>Вот - золотые слова. А софтовой альтернативы стало-быть нет ? :)
ИМХО - нет... ибо то оборудование продается, как мне кажется, не для того, чтобы каналы работали, а для того, чтобы деньги срубить... ибо в каком же офисе постоянно передаются одни и те же гиговые файлы? а запрос баз данных - он не так уж велик и, если база написана правильно, не сильно избыточен - у меня работала в Одессе программа с базой в Москве через public internet.
Ну, можно поставить большое окно tcp и включить компрессию - максимум
А по поводу коэффициента сжатия - как инженер-разработчик скажу аксиому
"Для любой разработаной вами системы и любого образца для сравнения можно подобрать набор тестов и критериев, при которых именно ваша система будет выигрывать в заданное число раз"
Начнём с того, что a-la MPEG они не сжимают ;-)
(ради эксперимента - попробуйте в своей фильмотеке найти два одинаковых фрейма)
Oracle возможно и сжимают, но что-то мне подсказывает, что это только если при кривой настройке самого Oracle.
Вообще заявления о сжатии чего-либо, а тем более потока рельного времени в разы - сильно напоминает давнюю историю про украинские чудо-модемы ;-)
Может это они и есть ? ;-)
>Начнём с того, что a-la MPEG они не сжимают ;-)
>(ради эксперимента - попробуйте в своей фильмотеке найти два одинаковых фрейма)Если сходить по ссылке приведеной выше и посмотреть на параметры девайсов,
то мы увидим, что все они оснащены не слабыми накопителями - например самая старшая версия имеет на борту 500Gb винт (2*250Gb). Интересно зачем ? Так, вот - спецы из этой самой конторы говорят, что для хранения словаря.>Oracle возможно и сжимают, но что-то мне подсказывает, что это только если
>при кривой настройке самого Oracle.Не совсем понятно, что значит кривая настройка и где чего в Oracle по этому поводу надо настраивать. Если юзер постоянно молотит один и тот-же запрос через oci к серваку пойдут одинаковые пакеты... Я где-то не прав ?
>Вообще заявления о сжатии чего-либо, а тем более потока рельного времени в
>разы - сильно напоминает давнюю историю про украинские чудо-модемы ;-)Меня тоже - это сильно озадачивает. Т.е. получается что-бы "закомпресировать" девайс должен получить изрядную порцию данных, обработать (найти в словаре - на HDD объемом 500Gb) и если в словаре нет данных - изменить содержимое словаря... Там наверное HDD с ассоцитивной адресацией. :)
>Может это они и есть ? ;-)
Вот я и заказал демонстрацию в своем офисе....
"...
Последовательностей (Network Sequence Mirroring - NSM). Также основанная на алгоритмах анализа ДНК, NSM отличается от существующих систем кэширования, тем, что способна оптимизировать передачу файлов в сотни Гбайт, если в самом файле произошли небольшие изменения. Подробнее о NSM.
..."Я уж не знаю сколько лет существует rsync, но это наверное узнать не
трудно. Судя поhttp://lists.samba.org/archive/rsync/
эдак с августа 2000. Может и еще раньше. И никаких, блин, молекул. ;-)
/poige
>
>Я уж не знаю сколько лет существует rsync, но это наверное узнать
>не
>трудно. Судя по
>
> http://lists.samba.org/archive/rsync/
>
>эдак с августа 2000. Может и еще раньше. И никаких, блин, молекул.
>;-)Ok. При изменении всего одного байта в файле rsync будет передавать файл целиком... А как быть например с VoIP - у меня эта позиция дает тоже не малый трафик ?
[...]
>
>Ok. При изменении всего одного байта в файле rsync будет передавать файл
>целиком... А как быть например с VoIP - у меня эта
^^^^^^^^Вам что-то мешает делать правильные логические выводы?...
>позиция дает тоже не малый трафик ?
Можно попробовать "более другие" "кодеки"...
/poige
--
http://www.i.morning.ru/~poige/
>[...]
>>
>>Ok. При изменении всего одного байта в файле rsync будет передавать файл
>>целиком... А как быть например с VoIP - у меня эта
>^^^^^^^^
>
>Вам что-то мешает делать правильные логические выводы?...Видимо, что-то мешает... Без Вашей помощи ну прямо никак.
>
>>позиция дает тоже не малый трафик ?
>
>Можно попробовать "более другие" "кодеки"...Например ? Впрочем я и сам могу перечислить поддержывемые
Definity кодеки. Естественно я их пробовал и остановился на
тех которые обеспечивают необходимое качество. Только не кажется ли
Вам, что мы далеко ушли от темы ?
>
>/poige
>--
>http://www.i.morning.ru/~poige/
>>[...]
>>>
>>>Ok. При изменении всего одного байта в файле rsync будет передавать файл
>>>целиком... А как быть например с VoIP - у меня эта
>>^^^^^^^^
>>
>>Вам что-то мешает делать правильные логические выводы?...
>
>Видимо, что-то мешает... Без Вашей помощи ну прямо никак.во-во. rsync, как-раз, из-за одного байта весь файл не передает...
>
>>
>>>позиция дает тоже не малый трафик ?
>>
>>Можно попробовать "более другие" "кодеки"...
>
>Например ? Впрочем я и сам могу перечислить поддержывемые
>Definity кодеки. Естественно я их пробовал и остановился на
>тех которые обеспечивают необходимое качество. Только не кажется ли
>Вам, что мы далеко ушли от темы ?Соглашусь. Кстати, причинами, в основном, послужили ваши "ляпы"
в этой теме./poige
>>
>>Видимо, что-то мешает... Без Вашей помощи ну прямо никак.
>
>во-во. rsync, как-раз, из-за одного байта весь файл не передает...
>>Если не сложно - какими опциями я должен воспользоваться, что-бы файл не передавался целиком.
sap-qualitet@rsync>rsync --version
rsync version 2.4.6 protocol version 24
>>тех которые обеспечивают необходимое качество. Только не кажется ли
>>Вам, что мы далеко ушли от темы ?
>
>Соглашусь. Кстати, причинами, в основном, послужили ваши "ляпы"
>в этой теме.Терпимие надо быть к людям. :) Или я Вас чем-то обидел ? В этом случае прошу прощения.
[...]
>Если не сложно - какими опциями я должен воспользоваться, что-бы файл не
>передавался целиком.AFAIR, по-умолчанию, когда передается файл с одного хоста на другой,
используется "delta"-режим. Укажите ключ "-v", чтобы
посмотреть подробности о передаче...
>[...]
>>Соглашусь. Кстати, причинами, в основном, послужили ваши "ляпы"
>>в этой теме.
>
>Терпимие надо быть к людям. :) Или я Вас чем-то обидел ?
>В этом случае прошу прощения.Вы считаете, я в чем-то несправедлив к вам? :-)
/poige
>>Если не сложно - какими опциями я должен воспользоваться, что-бы файл не
>>передавался целиком.
>
>AFAIR, по-умолчанию, когда передается файл с одного хоста на другой,
>используется "delta"-режим. Укажите ключ "-v", чтобы
>посмотреть подробности о передаче...
>>Специально проверил передачу файла размером 300Mb.
Последовательность следующая:
1.Скопировал файл
master@rsync:outbox>rsync master_zubr2.dta.gz sun::replication
Передано 18313 пакетов.
2.Повторил копирование
master@rsync:outbox>rsync -u master_zubr2.dta.gz sun::replication
Передано 25 пакетов.
3.Изменил первый байт в исходном файле, повторил копирование.
master@rsync:outbox>rsync -u master_zubr2.dta.gz sun::replication
Передано 18313 пакетов.Вмомент повторного копирования в целевом каталоге вижу файл
14078555 Oct 1 18:18 .master_zubr2.dta.gz.TgaW50
^^^^^^^^ Размер постоянно растет. Т.е. все работает как при обычном копировании. По завершении временный файл мувится в целевой.
Если смотреть truss'ом то целевой (существующий) файл в начале копирования открывается с опцией ro по окончании с rw.
>VTUN например сжимает трафик используя zlib или lzo. А данное оборудование ужимает
>трафик а-ля MPEG, т.е. повторяющиеся "фреймы" складываются в словарь и заменяются
>при передаче на ключи. Например (со слов представителя фирмы поставляющей девайсы)"когда вы говорите, такое ощущение, что вы бредите"
(c) из кинофильма "И. В. меняет профессию".
MPEG -- формат сжатия "__с__ __потерями__". Это {{
>трафик Oracle сжимается минимум в 4 (четыре) раза. Для некоторых протоколов
>приводится цифра в 10 раз. Так, что это актуально не только
>для передачи файлов.}} тоже бредятина. Любой протокол с высокым уровнем избыточности
будет "жаться" "на ура" при помощи "Huffman and Related Compression Techniques":http://www.faqs.org/faqs/compression-faq/part2/section-1.html
/poige
--
http://www.i.morning.ru/~poige/
>>VTUN например сжимает трафик используя zlib или lzo. А данное оборудование ужимает
>>трафик а-ля MPEG, т.е. повторяющиеся "фреймы" складываются в словарь и заменяются
>>при передаче на ключи. Например (со слов представителя фирмы поставляющей девайсы)
>
>"когда вы говорите, такое ощущение, что вы бредите"
>
> (c) из кинофильма "И. В. меняет профессию".
>
>MPEG -- формат сжатия "__с__ __потерями__". Это {{
>
А кто сказал, что используется MPEG ?
Ok. Если не понятно, что я хотел сказать. Тогда более просто - используется MSR (http://www.apt-reducer.ru/Peribit/msr.html) протокол.>>трафик Oracle сжимается минимум в 4 (четыре) раза. Для некоторых протоколов
>>приводится цифра в 10 раз. Так, что это актуально не только
>>для передачи файлов.
>
>}} тоже бредятина. Любой протокол с высокым уровнем избыточности
>будет "жаться" "на ура" при помощи "Huffman and Related Compression Techniques":
>
> http://www.faqs.org/faqs/compression-faq/part2/section-1.html
>
>/poige
>--
>http://www.i.morning.ru/~poige/А, что происходит на практике - через vtun с lzo трафик за август 11Gb (только Oracle), а за июль 11.5Gb через обычный тунель без сжатия.
Извините не совсем понятно, что имелось ввиду под "тоже бредятина" - от 4 до 10 раз - это мало или много ?
>>>VTUN например сжимает трафик используя zlib или lzo. А данное оборудование ужимает
>>>трафик а-ля MPEG, т.е. повторяющиеся "фреймы" складываются в словарь и заменяются
>>>при передаче на ключи. Например (со слов представителя фирмы поставляющей девайсы)
>>
>>"когда вы говорите, такое ощущение, что вы бредите"
>>
>> (c) из кинофильма "И. В. меняет профессию".
>>
>>MPEG -- формат сжатия "__с__ __потерями__". Это {{
>>
>
>
>А кто сказал, что используется MPEG ?А не вы ли написали '... трафик а-ля MPEG, т.е. повторяющиеся
"фреймы" складываются в словарь ...'?...>>>трафик Oracle сжимается минимум в 4 (четыре) раза. Для некоторых протоколов
>>>приводится цифра в 10 раз. Так, что это актуально не только
>>>для передачи файлов.
>>
>>}} тоже бредятина. Любой протокол с высокым уровнем избыточности
>>будет "жаться" "на ура" при помощи "Huffman and Related Compression Techniques":
>>
>> http://www.faqs.org/faqs/compression-faq/part2/section-1.html
>>
>>/poige
>
>А, что происходит на практике - через vtun с lzo трафик за
>август 11Gb (только Oracle), а за июль 11.5Gb через обычный
>тунель без сжатия.
>Извините не совсем понятно, что имелось ввиду под "тоже бредятина" - от
>4 до 10 раз - это мало или много ?Бредятина в том, что:
1) передача файлов сама по себе не бывает, для этого тоже
используется протокол.2) в 4-10 раз -- ничего необычного, как уже писал, зависит
от "рыхлости" протокола.P. S. В vtun, насколько помню, помимо параметров компрессии, есть
еще куча вариантов самих протоколов и способ соединения. Все они
имеют свои особенности и сво-ва. /dev/hands, как принято писать в
*nix-мире, тоже очень влияют./poige
>
>А не вы ли написали '... трафик а-ля MPEG, т.е. повторяющиеся
>"фреймы" складываются в словарь ...'?...
>Наверное я не правильно использовал "a-la". Хотел сказать <как MPEG>. :)
>Бредятина в том, что:
>
>1) передача файлов сама по себе не бывает, для этого тоже
>используется протокол.
>Вне всяких сомнений. :)
>2) в 4-10 раз -- ничего необычного, как уже писал, зависит
>от "рыхлости" протокола.
>
>P. S. В vtun, насколько помню, помимо параметров компрессии, есть
>еще куча вариантов самих протоколов и способ соединения. Все ониЗа все время использования vtun я обнаружил, что можно использовать:
# proto - Protocol.
# 'tcp' - TCP protocol.
# 'udp' - UDP protocol.
#
# 'tcp' is default for all tunnel types.
# 'udp' is recommended for 'ether' and 'tun' only.
#
# This option is ignored by the client.# compress - Enable 'yes' or disable 'no' compression.
# It is also possible to specify method:
# 'zlib' - ZLIB compression
# 'lzo' - LZO compression
# and level:
# from 1(best speed) to 9(best compression)
# separated by ':'. Default method is 'zlib:1'.
# Ignored by the client.Вот настройки которые я использовал.
type tun; # IP tunnel
proto udp; # UDP protocol
comp lzo:9; # LZO compression level 9>имеют свои особенности и сво-ва. /dev/hands, как принято писать в
>*nix-мире, тоже очень влияют.Буду очень признателен если Вы подскажите где мне надо спрямить пальчики. :)
>За все время использования vtun я обнаружил, что можно использовать:
[skip]
>Буду очень признателен если Вы подскажите где мне надо спрямить пальчики. :)
>
Прежде всего - эффективность работы компрессии зависит от размера mtu - чем больше, тем, ессно лучше, и еще желательно, чтобы в окно укладывалось по возможности целое количество пакетов - так заголовки сжимаются эффективнее. Если хочется сохранить малый mtu для работы с инетом, то можно уложить туннель в туннель- первый с максимально возможным размером для компрессии, а второй просто нарежет эти пакеты кусочками и передаст. Дополнительно замечу - здесь уже упоминалось, что Оракл сам жмет свои данные - так что выигрыш возможен лишь за счет заголовков, и еще - Оракл очень чувствителен к задержкам, зараза - на спутниковых каналах хамит.
По поводу VoIP - там поток уже настолько ужат, что его дальнейшая компрессия вызовет только увеличение объема информации и еще увеличит задержки.
>>>VTUN например сжимает трафик используя zlib или lzo. А данное оборудование ужимает
>>>трафик а-ля MPEG, т.е. повторяющиеся "фреймы" складываются в словарь и заменяются
>>>при передаче на ключи. Например (со слов представителя фирмы поставляющей девайсы)
>>
>>"когда вы говорите, такое ощущение, что вы бредите"
>>
>> (c) из кинофильма "И. В. меняет профессию".
>>
>>MPEG -- формат сжатия "__с__ __потерями__". Это {{
>>
>
>
>А кто сказал, что используется MPEG ?
>Ok. Если не понятно, что я хотел сказать. Тогда более просто -
>используется MSR (http://www.apt-reducer.ru/Peribit/msr.html) протокол.
то есть выделяют максимально длинные,повторяющиеся битовые цепочки..в реальном времени и в произвольном объеме данных?
Нда..что-то ребята поскромничали - надо бы им свой алг. на нобелевку
было двигать - если они правы, то для расшифровки любого генома, требуется секунд 5 ;-) Прогнал через девайс, глянул полученую базу - и готова!
Кстати если ПРИМЕНЯТЬ только этот ГИПОТЕТИЧЕСКИЙ алг, то скорость
передачи данных между конечными клиентами должна УМЕНЬШАТСЯ до 2 раз.
(точнее промежуток времени между началом передачи и окончанием приема
должен увеличиваться), правда при уменьшении нагрузки на канал.
>>>трафик Oracle сжимается минимум в 4 (четыре) раза. Для некоторых протоколов
>>>приводится цифра в 10 раз. Так, что это актуально не только
>>>для передачи файлов.
>>
>>}} тоже бредятина. Любой протокол с высокым уровнем избыточности
>>будет "жаться" "на ура" при помощи "Huffman and Related Compression Techniques":
>>
>> http://www.faqs.org/faqs/compression-faq/part2/section-1.html
>>
>>/poige
>>--
>>http://www.i.morning.ru/~poige/
>
>А, что происходит на практике - через vtun с lzo трафик за
>август 11Gb (только Oracle), а за июль 11.5Gb через обычный
>тунель без сжатия.
А что вы ожидали увидеть ? современные СУБД сами компрессируют свои данные при передачи. А lzo в вашем примере, сжал только заголовки и некоторые служебные данные протоколов(прочее уже запакованно). И никто лучше этого не сделает, Есть такая вешч как кол-во информации, применительно к теории передачи, это минимальное число бит требуемых для представления информации, все современные алгоритмы подходят достаточно близко к этому пределу и существенно сжать уже сжатый файл НЕВОЗМОЖНО.>Извините не совсем понятно, что имелось ввиду под "тоже бредятина" - от
>4 до 10 раз - это мало или много ?
это практически невероятно ;-)
Максимум что у них РЕАЛЬНО есть - эффективный механизм кеширования..
симметричный синхронный кеш ;-)..и работать это может только на очень НАДЁЖНОМ канале..
Да и похоже это всё на 'РОГА И КОПЫТА' ;-)
ребята получили нехило денег(о чём так и сказали)
и теперь оправдываются перед инвестором.По кол-во прессрелизов в месяц компания точно держится CISCO и IBM -
~4-5 штук в месяц на подразделение..может это международная норма ? ;-)
"Изучив Ваше коммерческое предложение о поставке каналообразующей аппаратуры, мы приняли решение приобрести некоторое количество травы, которую Вы курите...." Ж8-)>Нда..что-то ребята поскромничали - надо бы им свой алг. на нобелевку
>было двигать - если они правы, то для расшифровки любого генома, требуется
>секунд 5 ;-) Прогнал через девайс, глянул полученую базу - и
>готова!
Нобелевки маловато будет - ребята одним махом отменили теорию информации, теорию передачи сигналов и добрую половину разделов математики... да еще и машину времени придумали!!!! ибо из простейших соображений следует, что время отклика фильтра не может быть меньше интервала оценки, т.о. для ужатия гигового файла этот файл требуется полностью принять. Начать передавать сразу и оценивать по мере накопления? И рвать установившуюся сессию для повторной передачи по оптимизированому коду? а там и в третий, надцатый? бррр... Даже оптимизированые фильтры предсказания Калмана-Бьюси (обобщенные) таких чудес не обещают.>
>>Извините не совсем понятно, что имелось ввиду под "тоже бредятина" - от
>>4 до 10 раз - это мало или много ?
>это практически невероятно ;-)
Вероятно - если я напишу скрипт, который 10 000 раз будет повторять один запрос к базе данных и принимать ответ, который будет ессно тоже одинаковым, то выигрыш можно поиметь... то, что я писал о критериях оценки.>Максимум что у них РЕАЛЬНО есть - эффективный механизм кеширования..
> симметричный синхронный кеш ;-)..и работать это может только на очень НАДЁЖНОМ
>канале..
И со всеми недостатками механизма кеширования - хотя опять же, если я вместо команды распечатать 50 копий 50 раз пошлю задание на печать - выигрыш будет - но от задержек на оценку, потерь при смене заданий и пр. не уйти... Увы, математику и законы сохранения никто не отменил.
Пара замечаний:
1. Меня впечатлила модель http://www.apt-reducer.ru/Peribit/sm-500.html (500 Гбайт винтового пространства). Обалдеть, я бы лучше за такие бабки канал расширил или нормального железа купил.
2. В перечне их клиентов есть одна контора из которой я уволился пару меняцев назад. Дык вот, не использовали мы никогда их оборудование (уж мне ли не знать)...
>2. В перечне их клиентов есть одна контора из которой я уволился
>пару меняцев назад. Дык вот, не использовали мы никогда их оборудованиеИ я нашел контору в которой работаю до сих пор ... нет у нас их железа и никогда небыло ...
>(уж мне ли не знать)...
вот-вот ...
>Пара замечаний:
>1. Меня впечатлила модель http://www.apt-reducer.ru/Peribit/sm-500.html (500 Гбайт винтового пространства). Обалдеть, я бы
>лучше за такие бабки канал расширил или нормального железа купил.
>2. В перечне их клиентов есть одна контора из которой я уволился
>пару меняцев назад. Дык вот, не использовали мы никогда их оборудование
>(уж мне ли не знать)...Тема получила продолжение. :) Установили нам эту железку в так называемом "profile mode" - т.е. реально используется один девайс и с него можно снимать статистику как-бы он сжимал информацию. После 2-х часов накопления информации мы увидели, что даннные сжимаются почти в три раза (х2.89)...
После чего менеджер предложил подписать договор на поставку второго девайса. :)) Дескать устройство дорогое и нужны гарантии...
Устройство запломбировано, но имеет достаточно большие отверствия в передней рещетке: через которые явно просматриваются: ATX блок питания, обычная материнка со здоровенным радиатором на проце, и какая-то плата PCI с двумя 100BaseT, винчестера невидно. Вот, что показывает nmap:PORT STATE SERVICE
22/tcp open ssh
443/tcp open https
MAC Address: 00:02:B3: <<skip>> (Intel)
Device type: X terminal|load balancer
Running: Neoware NetOS, HP embedded, Cisco embedded
OS details: Cisco 11151/Arrowpoint 150 load balancer, Neoware (was HDS) NetOS V. 2.0.1 or HP Entria C3230AПосле изменения IP - адреса требуется перезагрузка...
Вобщем imho выгоднее свою оптику проложить. :)
>
>Тема получила продолжение. :) Установили нам эту железку в так называемом "profile
>mode" - т.е. реально используется один девайс и с него можно
>снимать статистику как-бы он сжимал информацию. После 2-х часов накопления информации
>мы увидели, что даннные сжимаются почти в три раза (х2.89)...
>После чего менеджер предложил подписать договор на поставку второго девайса. :)) Дескать
>устройство дорогое и нужны гарантии...Неплохо, однако, демонстрация устраивается - я в экстазе Ж8-)...
Интересно было бы посмотреть, что оно дает _реально_
>
>Неплохо, однако, демонстрация устраивается - я в экстазе Ж8-)...
>Интересно было бы посмотреть, что оно дает _реально_
Пока только графики рисует и воздух греет. :)
Орокловый трафик жмет почти в 10 раз... vtun - отдыхает. :)
Обещали через пару недель второй девайс...
>
>Пока только графики рисует и воздух греет. :)
>Орокловый трафик жмет почти в 10 раз... vtun - отдыхает. :)
>Обещали через пару недель второй девайс...
Ждем оценки Ж8-)
прикольная на@#$^ка ;-) Интересно, чем все это закончится ;-)