Работа сетей Ethernet с медленными каналами связи, методы сопряжения и конвертации Опции

[Волощенко]

Здравствуйте!
Кто сталкивался с подобной проблемой, когда разные фрагменты сети Ethernet, отстоящие друг от друга на десятки километров, соединены между собой низкоскоростными телекоммуникационными каналами связи типа ИКМ30. Такие каналы используют конверторы и структура канала такая: Ethernet-ИКМ30-Соединительная Линия-ИКМ30-Ethernet, а пиковая скорость передачи равна 64кБит*N, где N=1..30.
Для согласования скорости из Ethernet в ИКМ30, по моему представлению, используются такие методы:
- «шлюза», когда принятые, но еще не переданные пакеты накапливаются в очереди;
- «метод обратного давления», когда во время передачи текущего пакета, прием всех новых пакетов блокируется путем создания коллизий – одновременной передачей из конвертора в сеть Ethernet любого встречного пакета.
Мне нужно найти правильный выход, так как с помощью сниффера Ethereal четко заметил, что новый пакет приходит из Ethernet в конвертор до того, как в ИКМ30 передан предыдущий - а это приводит к отказам. Возможно, здесь есть еще тонкости применения в протоколе TCP/IP.
Хотел бы обменяться мнениями с теми, кто сталкивался с данной проблемой.
Спасибо.

[Krys]

насколько я представляю работу стека протоколов, при переполнении входного буфера вашего узкого горлышка, пакеты канального уровня теряются, никуда не деться. Но выше этого уровня есть транспортный, в частности, протокол TCP. Глубоко не вникал в его работу, но этот протокол должен по количеству недошедших пакетов подстраивать скорость передачи пакетов, чтобы они не терялись и не образовывались задержки, связанные с повторной передачей пакетов.
Я пока начинаю работать над похожей задачей и надеюсь, что так и будет, как я выше описал.
А все перечисленные вами ранее методы бесполезны: если в каналах разная скорость, это обязательно когда-то приведёт к невозможности доставить очередной пакет. Например, метод шлюза работает, пока не переполнится буфер. А потом всё равно пакеты потеряются.
Метод обратного давления приводит к бесполеному "торможению по цепочке". Вообще, коллизии имеют место только в полудуплексном режиме (я работаю с полным дуплексом на гигабитном изернете). В полном дуплексе есть механизм управления потоком, описываемый стандартом IEEE 802.3х (см. тему http://electronix.ru/forum/index.php?showtopic=15533 К стати, я с этим механизмом до конца так и не разобрался, так что был бы благодарен за помощь с русскоязычными текстами, поясняющими его). Что будет происходить: переполнится входной буфер вашего узкого горлышка, он будет оказывать обратное давление (хоть коллизией, хоть через механизм контроля потоков) на стоящее перед ним (по ходу передачи пакета) оборудование канального уровня (в первую очередь, коммутирующее), которое должно приостановить передачу пакета. В этом случае уже в этом предыдущем устройстве начнёт заполняться буфер и переполнится. Он опять должен оказывать обратное давление на предыдущее устройство и т.д. по цепочке. Это всё лишнее, если протокол TCP нормально выполняет свои функции и не даёт переполняться буферам, обеспечивая скорость "на грани"

[Shamil]

насколько я представляю работу стека протоколов, при переполнении входного буфера вашего узкого горлышка, пакеты канального уровня теряются, никуда не деться.

Почему же "никуда не деться" ?
Надо просто попросить устройства посылающие пакеты притормозиться, не дожидаясь полного заполнения буфера. Ну и буфер брать приличного размера, пакетов на 10..20 (наверное ).

Что будет происходить: переполнится входной буфер вашего узкого горлышка, он будет оказывать обратное давление (хоть коллизией, хоть через механизм контроля потоков) на стоящее перед ним (по ходу передачи пакета) оборудование канального уровня (в первую очередь, коммутирующее), которое должно приостановить передачу пакета. В этом случае уже в этом предыдущем устройстве начнёт заполняться буфер и переполнится. Он опять должен оказывать обратное давление на предыдущее устройство и т.д. по цепочке. Это всё лишнее, если протокол TCP нормально выполняет свои функции и не даёт переполняться буферам, обеспечивая скорость "на грани"

К сожалению, протокол TCP контролирует целостность только одного сеанса связи между двумя процессами (потребителями). А через узкое горло может быть организовано ничем не ограниченное множество независимых сеансов TCP.
Да и вообще, речь идет о передаче не IP пакетов, а пакетов Ethernet, в которые могут инкапсулироваться множество различных протоколов. Поэтому без управления потоком на MAC уровне не обойтись.
Я тоже только подступаюсь к этой проблеме. Посколько разбираться со всеми нюансами нет времени, я решил взять микросхему свича KS8993M фирмы Micrel, которая уже содержит в себе реализацию механизмов контроля потока. Один из 3-х портов этого свича может отдавать пакеты по MII интерфейсу, и я собираюсь эти пакеты упаковывать в поток E1 на своей скорости, а контроль переполнения очередей возлагаю на свич, который судя по его описанию умеет это делать.
Если у вас нет требований по индустриальному исполнению, есть еще более удобный свич фирмы Infineon ADM6993/X, у него третий порт может отдавать пакеты в формате HDLC на вашей скорости.

[Волощенко]

Лучше бы работать по методу квитирования пакетов, но этот режим устанавливает сервер, а не мой конвертор.
По этому напрашивается такая мысль - модифицировать метод "скользящего окна", тем что на определенном протокольном этапе перехватывать размер допускаемого к приему окна, «вручную» изменять в нем число разрешенных к передаче в окне кадров, например, с M до 1-го и далее передавать в направлении сервера. Таким образом, мы возвращаемся к квитированию.

[Krys]

Лучше бы работать по методу квитирования пакетов, но этот режим устанавливает сервер, а не мой конвертор.
По этому напрашивается такая мысль - модифицировать метод "скользящего окна", тем что на определенном протокольном этапе перехватывать размер допускаемого к приему окна, «вручную» изменять в нем число разрешенных к передаче в окне кадров, например, с M до 1-го и далее передавать в направлении сервера. Таким образом, мы возвращаемся к квитированию.

Вобщем-то этим и занимается протокол TCP

[Krys]

насколько я представляю работу стека протоколов, при переполнении входного буфера вашего узкого горлышка, пакеты канального уровня теряются, никуда не деться.

Почему же "никуда не деться" ?
Надо просто попросить устройства посылающие пакеты притормозиться, не дожидаясь полного заполнения буфера. Ну и буфер брать приличного размера, пакетов на 10..20 (наверное :cranky: ).

Почему именно такая цифра? С потолка? Вы знаете, что если скорости не совпадают, то любой буфер переполнится, какой большой бы он ни был. Зачем такой здоровый буфер? Это же надо сколько памяти? Железка будет очень дорогой. Обычно руководствуются правилом, что в буфере должно укладываться 2 пакета: чтобы протоколы TCP успели договориться на приёмной и передающей сторонах

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

Да и к чему я это всё пишу:

Что будет происходить: переполнится входной буфер вашего узкого горлышка, он будет оказывать обратное давление (хоть коллизией, хоть через механизм контроля потоков) на стоящее перед ним (по ходу передачи пакета) оборудование канального уровня (в первую очередь, коммутирующее), которое должно приостановить передачу пакета. В этом случае уже в этом предыдущем устройстве начнёт заполняться буфер и переполнится. Он опять должен оказывать обратное давление на предыдущее устройство и т.д. по цепочке.

Под переполнением я, разумеется, имел в виду заполнение до определённого порога, при котором посылается команда приостановки передачи. Но самое главное: вы представляете, что каждый раз при переполнении всё оборудование канального уровня от узкого места до источника пакетов будет подвержено распространению по цепочке кадра приостановки передачи, а после опустошения буфера - кадра возобновления передачи? Кому нужен весь этот бесполезный трафик, если гораздо проще поручить на передающем конце протоколу TCP подстроить оптимальную скорость посылки пакетов в сеть? И тогда весь механизм контроля потоков не пригодится.
А если ещё учесть, что на пути от источника пакетов до узкого горлышка возможно хоть один свич не поддерживает механизм контроля потоков? Тогда все старания этого механизма, весь паразитный трафик из кадров приостановки и возобновления передачи напрасны. Этот свич, не поддерживающий механизм контроля потока будет слать пакеты, и следующее по пути их распространения оборудование будет заполнять свой приёмный буфер. И он заполнится. Лишние пакеты всё равно начнут убиваться.
Пусть уж лучше протокол TCP возьмётся за эту работу.

К сожалению, протокол TCP контролирует целостность только одного сеанса связи между двумя процессами (потребителями). А через узкое горло может быть организовано ничем не ограниченное множество независимых сеансов TCP.

Каждый проткол задаёт скорость своего соединения, скорость делится пропорционально. Так что в целом скорость как раз благодаря действию всех протоколов TCP должна установиться на грани пропускной способности узкого горлышка.

Да и вообще, речь идет о передаче не IP пакетов, а пакетов Ethernet, в которые могут инкапсулироваться множество различных протоколов. Поэтому без управления потоком на MAC уровне не обойтись.

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

Я тоже только подступаюсь к этой проблеме. Посколько разбираться со всеми нюансами нет времени, я решил взять микросхему свича KS8993M фирмы Micrel, которая уже содержит в себе реализацию механизмов контроля потока. Один из 3-х портов этого свича может отдавать пакеты по MII интерфейсу, и я собираюсь эти пакеты упаковывать в поток E1 на своей скорости, а контроль переполнения очередей возлагаю на свич, который судя по его описанию умеет это делать.
Если у вас нет требований по индустриальному исполнению, есть еще более удобный свич фирмы Infineon ADM6993/X, у него третий порт может отдавать пакеты в формате HDLC на вашей скорости.

У меня лично Gigabit Ethernet, там со свичами с малым количеством портов пока проблема... я делаю вообще свич на ПЛИС.

[zltigo]

сли гораздо проще поручить на передающем конце протоколу TCP подстроить оптимальную скорость посылки пакетов в сеть?

Махровый идеализм :-)))).

я делаю вообще свич на ПЛИС.

Тогда это вообще не Ваша "проблема".

[Krys]

Махровый идеализм :-)))).

Позволю себе не согласиться: идеальным выглядит решение с механизмом контроля потоков. И вот оно, как раз, и разбивается о суровую правду жизни, которую я описывал ранее. Что не все устройства это поддерживают, что гоняется лишний трафик и т.д. С моим мнением коррелируют утверждения авторов книги [Компьютерные сети: Принципы, технологии, протоколы: Учебник для вузов/ Виктор Григорьевич Олифер, Наталия Алексеевна Олифер. - СПб.: Питер, 2002. - 669[3] с.: ил. - (Учебник для вузов)], если не ошибаюсь.
А вот протокол TCP, как раз должен выполнять требуемые действия по подстройке скорости. Я детально в нём не разбирался, но определённые понятия имею.

Тогда это вообще не Ваша "проблема".

Может, мы друг друга неправильно поняли, но на мой взгляд, это и есть моя проблема, т.к. я должен реализовать в свиче, в частности, и механизм контроля потоков.

[zltigo]

А вот протокол TCP, как раз должен выполнять требуемые действия по подстройке скорости. Я детально в нём не разбирался, но определённые понятия имею.

Конретные реализации стеков конкретно на это и на обработку (только фиксация для статистики)
аппаратных ошибок любезно доставляемых Вашим switch плюют :-( Это я имел ввиду под
идеализмом :-(. Собственно этот бардак начался с распространения интернета, когда что-либо кто-либо перестал гарантировать, ну а на локальные сети "автоматически" распространилось :-(

[Harbour]

Можете сделать бридж, у которого медленный интерфейс будет с более мелким mtu, ну и буфер поболе. Буду лепить похожую байду через месяц - и в мыслях нету так все усложнять - похерил пакет и делов-то.

[kolobok0]

Можете сделать бридж, у которого медленный интерфейс будет с более мелким mtu, ну и буфер поболе. Буду лепить похожую байду через месяц - и в мыслях нету так все усложнять - похерил пакет и делов-то.

дело вот в чём...
сам разговор об абстрактном Ethernet конечно же занимательная весчь, но мягко говоря бесполезная... При реализации стэка протоколов Вы будете реализовывать все нижележащие протоколы. Если идёт речь о TCP/IP то Вам придётся покопаться с MAC уровнем, с IP уровнем, протоколами ARP (скорее всего захотите поддержать), протокол ICMP (скорее всего захотите поддержать), рядом лежащий UDP...
Дык вот, если речь идёт об "узком" горлышке IP уровня, который может ДЕФРАГМЕНТИРОВАТЬ пакеты кде то там и у Вас должным образом должна производиться сборка - то тогда "первый удар" будет принимать именно он. Данный уровень не содержит механизма регулирования пропускной способности канала. И тут нужен кэш. И решение таких проблем как время жизни разрозненных пакетов при сборке. В принцепе, чтоб не быть голословным - вот ссылки, возможно кому нить они помогут...

русско язычная ссылка
ссылка на -гнездо- протоколов

с уважением
(круглый)

[Волощенко]

Спасибо за ответы и ссылки на документацию.
Есть мнение, что согласование высокой скорости Ethernet и медленной E1 (TDM,PCM30) достаточно сделать методом «обратного давления», создавая коллизии на аппаратном МАС-уровне. В этом случае, когда низкоскоростной канал все еще находится в режиме передачи предыдущего пакета, нужно на ранних этапах распознать поступление нового пакета Ethernet и, пока он продолжает поступать, сгенерировать свой встречный. Тогда встречное устройства на МАС-уровне распознает коллизию, прекратит передачу и попробует с некоторой задержкой ее повторить (что может выполняться несколько раз), и это в итоге даст нужную нам задержку, а значит и согласование скорости.
1. Непонятным является то, куда, в какую физическую линию, генерировать «свой встречный» пакет? Ведь есть два провода входных и два выходных. Если не в ту, из которой поступает новый пакет (два входных провода), то как быть с полнодуплексным режимом, получается, что для него этот метод не работает?
2. Все-таки должны быть универсальные методы согласования. Кто-то ж их уже опробовал?

[zltigo]

Есть мнение...

Ошибочное. Подробности были в личном письме.

[Joe]

Спасибо за ответы и ссылки на документацию.
Есть мнение, что согласование высокой скорости Ethernet и медленной E1 (TDM,PCM30) достаточно сделать методом «обратного давления», создавая коллизии на аппаратном МАС-уровне. В этом случае, когда низкоскоростной канал все еще находится в режиме передачи предыдущего пакета, нужно на ранних этапах распознать поступление нового пакета Ethernet и, пока он продолжает поступать, сгенерировать свой встречный. Тогда встречное устройства на МАС-уровне распознает коллизию, прекратит передачу и попробует с некоторой задержкой ее повторить (что может выполняться несколько раз), и это в итоге даст нужную нам задержку, а значит и согласование скорости.
1. Непонятным является то, куда, в какую физическую линию, генерировать «свой встречный» пакет? Ведь есть два провода входных и два выходных. Если не в ту, из которой поступает новый пакет (два входных провода), то как быть с полнодуплексным режимом, получается, что для него этот метод не работает?
2. Все-таки должны быть универсальные методы согласования. Кто-то ж их уже опробовал?

А не проще решить проблему применением готового моста? Видел реализацию на MB86976 (Fujitsu Ethernet Bridge Controller см. рисунок). У него с одной стороны подключается LIU Ethernet а с другой - WAN-interface. Еще правда к нему надо DRAM подцепить. Скорость в WAN-части - до 8 Мбит/с. Придется, конечно, повозится с "N*64" и синхронизацией в ИКМ-части, но зато проблема с "запихиванием слона в запорожец" решиться однозначно.

[iosifk]

Здесь говорилось о:

микросхему свича KS8993M фирмы Micrel, которая уже содержит в себе реализацию механизмов контроля потока. Один из 3-х портов этого свича может отдавать пакеты по MII интерфейсу, и я собираюсь эти пакеты упаковывать в поток E1 на своей скорости, а контроль переполнения очередей возлагаю на свич, который судя по его описанию умеет это делать.


Вот кусок перевода даташита для KS8995, просто для справки:

Поддержка ограничения объема обмена информацией
KS8995MA поддерживает аппаратное ограничение объема обмена информацией, как на стороне приема, так и на стороне передачи независимо для каждого порта. Это также поддерживает ограничение объема обмена информацией для приоритетной или неприоритетной среды. Предел объема обмена информацией начинается от 0 Кб/сек и подходит к частоте работы линии с шагом в 32Кб/сек.
KS8995MA использует одну секунду как временной интервал для паузы. В начале каждого интервала, счетчик обнуляется, и механизм, определяющий объем обмена информацией начинает считать число байтов, переданных/полученных в течение этого интервала.
На стороне приема, если число принятых байтов превышает запрограммированный предел, то коммутатор прекратит получать пакеты для этого порта, пока интервал, длительностью в одну секунду не истечет. Есть опция, предусматривающая управление потоком данных, используемая для того, чтобы предотвратить потери пакетов. Если предел на ограничение объема обмена информацией запрограммирован на скорости большие или равные 128 Кб/сек, и счетчик байтов находится на уровне, отстоящем на 8 КБ ниже уровня предела, то будет вызвано управление потоком данных. Если предел на ограничение объема обмена информацией запрограммирован на скорости ниже чем 128 Кб/сек, и счетчик байтов находится на уровне, отстоящем на 2 КБ ниже предела, то в этом случае также будет вызвано управление потоком данных.
На стороне передачи, если число байтов превышает запрограммированный предел, коммутатор прекратит передавать пакеты через этот порт, пока интервал длительностью в одну секунду не истечет.
Если допускается обслуживание с приоритетами, то KS8995MA может поддержать различный уровень объема обмена информацией как для высоко-приоритетных и для низко-приоритетных пакетов. Такой режим обслуживания может быть запрограммирован в соответствующих регистрах управления режимами работы микросхемы.


Удачи!

[Волощенко]

Спасибо за информацию.
Удачное сравнение проблемы – «с запихиванием слона в запорожец».
Здесь у меня есть личный аспект – эта тема в работе, аппаратура изготовлена в малой партии, сейчас мною настраивается и нужно получить результат (сроки уже затянулись). Все ссылки на другие устройства очень интересны (думаю, всем и мне тоже), но принять я их сейчас не могу. Возможно, позже, так что вопрос о методе по прежнему актуален - надо закончить разработку. Вот такая ситуация.

[zltigo]

аппаратура изготовлена в малой партии, сейчас мною настраивается и нужно получить результат

Соболезнования :-(.

[Волощенко]

Привет Всем!!!
Заработали мои конверторы - это первая ласточка! Пишу это письмо через них. Скорость пока 4*64кбит/с, низковатая, как у черепахи, но по Интернету уже походил. Приятно то как
Подробности потом, вопросов и работы еще много...
Даже изменение прошло.

Сообщение отредактировал Волощенко - May 26 2006, 09:14

[Krys]

Есть мнение...

Ошибочное. Подробности были в личном письме.

Вай, зачем в личное письмо? Напишите, пожалуйста, сюда. Ведь это всем может быть интересно и полезно!

[Krys]

1. Непонятным является то, куда, в какую физическую линию, генерировать «свой встречный» пакет? Ведь есть два провода входных и два выходных. Если не в ту, из которой поступает новый пакет (два входных провода), то как быть с полнодуплексным режимом, получается, что для него этот метод не работает?
2. Все-таки должны быть универсальные методы согласования. Кто-то ж их уже опробовал? :excl:

В полнодуплексном режиме работает механизм контроля потоков http://electronix.ru/forum/index.php?showtopic=15533

[Волощенко]

Конвертор построен на CS8900A-CQ3, C8051F123 и XC9572XL. Его задача преобразовать полный или частичный поток Е1 в Ethernet (10Base-T) и обратно для передачи информации в SHDSL-трактах. Проблемы при выходе в Internet через сервер предприятия, похоже, уже нет, видимо, все неувязки решает TCP/IP. Результаты работы в полудуплексном режиме достаточно удовлетворительные. Проблемы остались при работе с подобными компьютерами в локальной сети через сетевое окружение, с ними просто нет связи (ни через Explorer, ни через Total Commander). Также были проблемы при организации видеоконференций. Видимо не хватает быстродействия и накопительного буфера со стороны Ethernet , а может там другие протоколы. Над эти сейчас тружусь, вооружившись Ethereal.
Информации по протоколам вроде бы много, но объять ее тяжело. А так как нет тематического руководства, то работа напоминает хождение по темному лабиринту без фонарика. Поэтому и вопросы.

Сообщение отредактировал Волощенко - May 31 2006, 14:23

[zltigo]

Скорость пока 4*64кбит/с, низковатая, как у черепахи, но по Интернету уже походил.

256 kbit/s, даже с учетом возможного наличия дополнительного протокола при паковке в E1 это
для "хождения по интернету" не совсем то, что можно охарактеризовать "как черепаха", ибо
скорость доступа ко многим ресурсам сети на уровне 10-20Kbytes/s я вляется обыденным и _привычным_ делом :-(. Где-то у Вас 'черепаха' в другом месте покопаласть....

[Волощенко]

Схема организации связи такая: Я отключаю свой компьютер от локальной сети, и ставлю два конвертора, так, чтобы между собой они были связаны по Е1, а каналами Ethernet подключались один к сети, а другой к моему компьютеру. При использовании 4 канальных интервалов (КИ) - пиковая скорость 256 kbit/s, с большим числом КИ в Е1 я пока еще не успел поработать. Экспериментировал с DounLoadMaster, загружая с Интернета pdf-файлы размером по 1Мбайт (используя при этом 4 КИ). DounloadMaster показал здесь пиковую скорость 8кбайт/с (т.е. 64 kbit/s), и загружал этот файл за время около 4 мин (здесь сетевая скорость 10Мбит/с). Таким образом, средняя скорость была около 30 kbit/s, в восемь раз ниже пиковой для 4-х КИ. Конечно, были потери, так как при детальном просмотре через sniffer, были видны сообщения типа:"TCP Previous segment lost", "TCP Retransmission". Так что черепашка действительно еще где-то зарыта.
Для справки этот же файл загружался напрямую, через сеть за 4 сек (без моего конвертора, при скорости в сети 100Мбит/с и с пиковой скорость до 500кбайт/с ).
Вопросы остались: Почему не удается связаться через конверторы с соседними компьютерами локальной сети предприятия? На ping они отвечаю без проблем, а вот просмотреть содержимое с помощью Windows Commander – не удается (хотя без конверторов это получается). Может сетевое управление осуществляется по другим протоколам, для которых транспортная задержка через конверторы является критической?

[zltigo]

Может сетевое управление осуществляется по другим протоколам, для которых транспортная задержка через конверторы является критической?

Задержка - нет, а потери смертельны.

[Harbour]

Я так понял что лишние пакеты Вы просто херите ?

[DS]

Схема организации связи такая: Я отключаю свой компьютер от локальной сети, и ставлю два конвертора, так, чтобы между собой они были связаны по Е1, а каналами Ethernet подключались один к сети, а другой к моему компьютеру. При использовании 4 канальных интервалов (КИ) - пиковая скорость 256 kbit/s, с большим числом КИ в Е1 я пока еще не успел поработать. Экспериментировал с DounLoadMaster, загружая с Интернета pdf-файлы размером по 1Мбайт (используя при этом 4 КИ). DounloadMaster показал здесь пиковую скорость 8кбайт/с (т.е. 64 kbit/s), и загружал этот файл за время около 4 мин (здесь сетевая скорость 10Мбит/с). Таким образом, средняя скорость была около 30 kbit/s, в восемь раз ниже пиковой для 4-х КИ. Конечно, были потери, так как при детальном просмотре через sniffer, были видны сообщения типа:"TCP Previous segment lost", "TCP Retransmission". Так что черепашка действительно еще где-то зарыта.
Для справки этот же файл загружался напрямую, через сеть за 4 сек (без моего конвертора, при скорости в сети 100Мбит/с и с пиковой скорость до 500кбайт/с ).
Вопросы остались: Почему не удается связаться через конверторы с соседними компьютерами локальной сети предприятия? На ping они отвечаю без проблем, а вот просмотреть содержимое с помощью Windows Commander – не удается (хотя без конверторов это получается). Может сетевое управление осуществляется по другим протоколам, для которых транспортная задержка через конверторы является критической?

TCP/IP специально предназначен для работы по каналам с возможными "узкими местами", где будт происходить отброс пакетов, превышающих лимит скорости. Поэтому через конверторы он у Вас и работает. Снижение скорости может происходит из-за наличия паразитного траффика в сети (broadcustы и прочее), который вполне может забить часть и так небольшой полосы.
Для Windowсовского NETBIOSа потери смертельны.

У нас есть Cronyxовский ковертер, который работает со скоростью 64 Кбит через SDH сеть на расстояние примерно 50 км. Соединены 2 компьютера с Linux, скорость 64 кбита достигается спокойно.

[Волощенко]

Помимо работы в Internet (на устойчивых к потерям протоколов TCP/IP), мои конверторы должны обеспечить связь двух удаленных компьютеров, или удаленного компьютера и сети (через DSL-тракт).
Здесь как я понимаю из Ваших ответов, при между-компьютерных обменах включаются уже другие протоколы, а именно Windows NETBIOS. Для них потери пакетов смертельны (в силу того, что нет механизма восстановления как у TCP/IP). В тоже время задержка в доставке пакетов не так страшна, как возможные их потери (может здесь решение!). Уменьшить загрузку конверторов можно, отсекая с помощью внутреннего адресного фильтра CS8900A посторонние пакеты (широковещательные и чужие).
Тогда возникают вопросы:
1. Возможна ли полноценная связь, если через конверторы, в направлении удаленного компьютера, пропускать только адресованные ему пакеты (по индивидуальному адресу на уровне Ethernet адресации с помощью адресного фильтра CS8900A)?
2. Как «подружится» с протоколами Windows NETBIOS, учитывая «заторможенность» конверторов и ограниченность буфера очереди для поступающих пакетов?

[DS]

Broadcustы пропускать обязательно, иначе не будет ничего работать. Через них определяется соотвествие IP адреса физическому, а NETBIOS использует их местами и для передачи команд.

Соединить две сети с Windows компьютерами узким каналом, чтоюы сохранилась работоспособность вряд ли получиться. Уж больно много каждый компьютер broadcustoв рожает. Соединяйте через машины - маршрутизаторы (или через D-linkи дешевые), так чтобы соединение было точка-точка.

Windows можно настроить для работы полностью через TCP/IP, но я в этом не спец.

[Krys]

Да, тут Вы правы, надо включать "NetBIOS over TCP/IP", тогда всё должно работать надёжно. Но без броадкастов не получить полный список компьютеров в "сетевом окружении". Хотя даже без этого списка мы должны "заходить" на компьютер и "видеть" его "расшаренные" папки, выполнив "поиск компьютера" и введя его IP-адрес (только при включенном NetBIOS over TCP/IP)

[DS]

В Netbios over TCP/IP есть возможность организовать name server на одной из машин, который позволяет работать NETBIOSу из разных IP сетей. Тогда не будут лезть broadcustы через узкий канал. Но как это все в Windows настраивается я понятия не имею.

[Волощенко]

Добрый день!
Работа по моему конвертору Ethernet-ИКМ(Е1 или TDM) подошла к концу. Поэтому благодарность всем за советы и подсказки. Прилагаю фото платы конвертора. Напомню, что максимальная скорость передачи через конвертор N*64кбит/с, где N=1..32 число задействованных тайм слотов потока Е1. Удалось достичь средней скорости 85% от максимума при связи двух компьютеров посредством этих конверторов через SHDSL-модемы.
Что хочется отметить. Стек протоколов TCP/IP сложен для понимания, но продуман его создателями и легко адаптируется ко всем задержкам тракта передачи. Замечено, что он постоянно изменяет скорость передачи, «пытаясь» достичь ее максимума. Это часто приводит к пере ретрансляции потерянных по его инициативе пакетов (может и из-за этого не удается достичь максимума). В общем, каких либо специальных методов согласования скоростей применять не пришлось (хотя в начале думалось, что без этого не обойтись).
Вся работа по перекодировке в конверторе легла на процессор C8051F123 от Silabs (около 90 MIPS), пришлось много программировать на С51 и ассемблере в среде uVision2 от Keil версии v7.08. Для себя я решил, что имеет смысл использовать фирменные конверторы, в том числе те, что были предложены при обсуждении.
Всем спасибо и удачи.

Эскизы прикрепленных изображений

 

[Harbour]

SHDSL сами делали ? Если да на каком чипсете ?

[Krys]

В общем, каких либо специальных методов согласования скоростей применять не пришлось (хотя в начале думалось, что без этого не обойтись).

Вобщем-то, как я и говорил где-то в этой теме... Протокол TCP сам всё сделает...

[zltigo]

Протокол TCP сам всё сделает...

1.Есть еще и другие протоколы, которые тоже "хотят" ходить по Ethernet.
2.Сделать то он сделает все, что может. И протоколы над ним - сделают все, что могут.
Но количество дополнительно потраченной пропускной способности канала сильно завист от "качества"
такого шлюза.

[Волощенко]

Ответ Harbour. Я лично разработал и программировал регенератор SHDSL (SHDSL-модем с возможностью дистанционного питания до 3 регенераторов с каждой стороны, делал мой напарник). Все уже работает почти год в полевых условиях. В обоих случаях использовались чипы SOCRATES (PEF22622) от Infineon. Впечатления о чипе - очень удачная немецкая разработка.
Ответ Krys. Я сначала искренне сомневался, но потом действительно понял, протокол все делает за Вас. Так что советы были не зря.
Ответ zltigo. В данном случае достигнуто 85% от пропускной способности шлюза. Я слышал, что другие сделали 95%. Я упирал на низкую стоимость, хотя можно было бы увеличить за счет аппаратурных затрат этот процент.

[zltigo]

Ответ zltigo. В данном случае достигнуто 85% от пропускной способности шлюза.

Я не об этом. Когда через этот шлюз пойдут несколько (или несколько десятков) даже TCP/IP
соединений что будет? Если шлюз не сможет забуферировать пик нагрузки и потеряет часть пакетов, то тут уже не 85% пропускной способности физического канала речь пойдет :-(.

[Волощенко]

Конверторы испытывались при связи удаленного компьютера с сервером (а также двух отдельно стоящих компьютеров) загрузкой больших файлов. Использовался сниффер Ethereal, а скорость оценивалась по показаниям FAR (или рассчитывалась вручную). Также был организован доступ в Internet, при обращении к нескольким сайтам, при одновременной загрузке с одного из них.
Этот конвертор как шлюз, не имеет большого буфера со стороны Ethernet, а только для двух пакетов. Так что сниффером были видны пере ретрансляции, когда протокол TCP/IP передавал плотные "окна" с большим количеством пакетов, но все накладки им регулировались.
Еще также включался/выключался механизм "отфильтровки" посторонних пакетов по МАС-адресу удаленного компьютера (имеется в CS8900A).

[TomaT]

У нас для примерно тех же целей (радиорелейка 4Е1+Ether) используется свитчик RTL8305+XC2S100.

[zltigo]

не имеет большого буфера со стороны Ethernet, а только для двух пакетов.

Для подключения одного host компьютера и при условии большой загрузки в каждый момент времени только по одному TCP/IP соединению "на вскику" два буфера должны дать вполне работоспособную систему, что и подтверждено экспериментом. Для для условий отличающихся от описанных число буферированных пакетов должно быть много больше, да и аппаратная фильтрация по один_свой+broadcast MAC не сможет помогать :-(.
И вывод:

Для себя я решил, что имеет с мысл использовать фирменные конверторы, в том числе те, что были предложены при обсуждении.

Совершенно правилен.
P.S.
Могу сюда для коллекции выложить фото подобной самоделки :-)
И несколько позже на более специализированном чипе.

[Волощенко]

to zltigo:
Задача была конкретная: получить "дешево-сердитый" конвертор. Что смог...
"Могу сюда для коллекции выложить фото подобной самоделки :-)
И несколько позже на более специализированном чипе."
Приветствуется

to TomaT
А как Вы решали аналогичные проблемы? В частности, накопление пакетов в очереди шлюза (задачу выравнивание скоростей)?

Сообщение отредактировал Волощенко - Aug 4 2006, 08:32

[zltigo]

Задача была конкретная: получить дешево-сердитый конвертор. Что смог...

Я ведь не в порядке "распальцовки", тем более, что история появления уже была четко изложена ранее. Просто для ориентации потенциальных последователей в ограничениях :-( накладываемыми
простыми решениями.
А Ваши бойцовские качества проявленные в "безнадежном предриятии" только заслуживают уважения!

Приветствуется

Пошел за фотоаппаратом....

[Волощенко]

Спасибо! Я тоже за то, что с виду якобы "простые" решения могут круто вылиться боком. Будущее за готовыми чипами от известных фирм, это я не оспариваю. Хотя тема сама по себе интересная.

[iosifk]

Спасибо! Я тоже за то, что с виду якобы "простые" решения могут круто вылиться боком. Будущее за готовыми чипами от известных фирм, это я не оспариваю. Хотя тема сама по себе интересная.

Коллеги! У меня есть к Вам вот какое предложение.
У меня по плану статей для Элтеха должна быть статья о коммутаторах каналов для Eth. на примере чипов фирмы Микрел. Но писать голую рекламу не хочется.
Что я предлагаю:
1. Вы можете предоставить мне результаты испытаний. Тогда в статье будет написано: "результаты испытаний.... получены - ваше_имя_И_e-mail"
2. Вы можете написать главу о ... о железе, о методике испытаний, о питании по проводам...о дальнейших рекомендациях при разработке.... короче о чем хотите. Тогда в статье будет авторы: "....и ваше_имя_И_e-mail"
3. Возможны другие варианты... пока не придумал какие...

Для этого достаточно по почте на iosifk@eltech.spb.ru кинуть письмо:
"Я хочу предложить..."

Удачи!

[dmivs]

Я пока начинаю работать над похожей задачей

Буду лепить похожую байду через месяц

Похоже вопрос "использовать спец. чипы vs ваять самому" того-же плана что и "C#/Java vs C/Assembler для встроенных систем" в соседнем топике.

Проект типа "впихнул и забыл" - надо быстренько "слепить байду" из чего попало и сдать проект.

Оборудование, которое надо будет потом поддерживать (не забываем про баги, которые в современных СБИС есть всегда), дорабатывать к новым требованиям и протоколам (та-же книга [Компьютерные сети: Принципы, технологии, протоколы] - "учтите, что через год половина информации из этой книги устареет") и т.д. - тут ИМХО такой поверхностный подход уже не годится...

Не зря же для решения вроде стандартной задачи "Ethernet чезер синхронный поток" вполне серьезные фирмы без конца новые "велосипеды" изобретают...

Сообщение отредактировал dmivs - Aug 4 2006, 11:09

[TomaT]

...
to TomaT
А как Вы решали аналогичные проблемы? В частности, накопление пакетов в очереди шлюза (задачу выравнивание скоростей)?

А никак, это у свитча голова по этому поводу болит, а FPGA только собирает/разбирает фреймы и заботится о их синхронизации; т.е. например для Е3 тактовая 34368кГц вот она и подается на RXC для данных которые со свитча идут, а на TXC подается синхра выделяемая E3-трансивером из HDB3 для данных с другой стороны релейки.

[Волощенко]

to TomaT
Может мне еще придется разрабатывать что-то подобное... По этому еще б небольшую структурную схему Вашего устройства: состав, что с чем связывается, и куда и на каких скоростях идут потоки, какие, где интерфейсы... Как сконфигурирован свитч, что подключается к радиорелейке.
Из сообщения все же не понятно как происходит согласование скоростей - опять все ложится на протокол TCP/IP? Какая связь между синхронными потоками Е1 и асинхронными Ethernet (где буферы пакетов)?
Если не секрет...

[TomaT]

Частью секрет, частью нет
4E1+Eth->Radio не очень удачный пример, я там сам еще не разобрался. Оно мне досталось AsIs.
Попробую описать Eth->E3. На самом деле не совсем E3, там у нас фрейм по другому собирается.

Буферы пакетов в свитче, он и согласует, так же как и в случае когда к 100Мб свитчу 10-и Мб сетевуха вешается.

Сообщение отредактировал TomaT - Aug 4 2006, 13:08

[Волощенко]

Было такое предложение-пожелание:

... Вы можете предоставить мне результаты испытаний.....

Результаты есть, я их прилагаю. Здесь удаленный компьютер соединялся со свичем и далее с сервером. Между ними были два конвертора Ethernet-TDM (т.е. то, для чего все это и разрабатывалось). Канал связи - это TDM (он же PCM-30, или SHDSL). Максимальная скорость канала Vmax равна N*64 кбит/с (или N*8 кбайт/с), где N - число задействованных канальных интервалов (тайм-слотов). Относительно Vmax оценивается коэффициент заполнения Кз, как отношенеи реальной скорости пересылки файлов к максимальной. Думаю, что Кз - это интегральная характеристика эффективности получаемого канала.
Испытания выполнены без применения "обратного давления" (back pressure - по натовской терминологии). Я испытал эту технологию в двух ее возможных модификациях (формирование коллизий при отсутствии свободного пространства в буферах), но она ухудшила результаты на процентов 20, поэтому от нее отказались. Вопросы есть по скорости туда и обратно, они отличаются при работе в локальной сети (в обратном направлении она низковата). Но при загрузке с интернетовских сайтов (а у нас предприятии достаточно мощный канал), коэффициент заполнения приближался к максимальному значению (в направлении от РС к серверу).
Так что вопросы плодятся и без нас...

Прикрепленные файлы

 p2.doc ( 75 килобайт ) Кол-во скачиваний: 909

 

[iosifk]

[quote name='Волощенко' date='Sep 25 2006, 19:08' post='157931']
Было такое предложение-пожелание:
[quote name='iosifk' post='141414' date='Aug 4 2006, 12:18']
... Вы можете предоставить мне результаты испытаний.....
[/quote]

Спасибо за информацию, буду переваривать.
Думаю, что эти результаты будут интересны не только мне...

[Victor®]

Здравствуйте!
Кто сталкивался с подобной проблемой, когда разные фрагменты сети Ethernet, отстоящие друг от друга на десятки километров, соединены между собой низкоскоростными телекоммуникационными каналами связи типа ИКМ30. Такие каналы используют конверторы и структура канала такая: Ethernet-ИКМ30-Соединительная Линия-ИКМ30-Ethernet, а пиковая скорость передачи равна 64кБит*N, где N=1..30.
Для согласования скорости из Ethernet в ИКМ30, по моему представлению, используются такие методы:
- «шлюза», когда принятые, но еще не переданные пакеты накапливаются в очереди;
- «метод обратного давления», когда во время передачи текущего пакета, прием всех новых пакетов блокируется путем создания коллизий – одновременной передачей из конвертора в сеть Ethernet любого встречного пакета.
Мне нужно найти правильный выход, так как с помощью сниффера Ethereal четко заметил, что новый пакет приходит из Ethernet в конвертор до того, как в ИКМ30 передан предыдущий - а это приводит к отказам. Возможно, здесь есть еще тонкости применения в протоколе TCP/IP.
Хотел бы обменяться мнениями с теми, кто сталкивался с данной проблемой.
Спасибо.

Здравствуйте!
Посмотрите на это:
http://products.zarlink.com/product_profiles/ZL50120.htm

[Волощенко]

К Victor®, спасибо за ссылку на Zarlink!
Мы работаем с их продукцией, но эту схему проглядел.
Информация новая и интересная (как раз требуется добавить функцию VLAN и Ethernet 10/100). Огорчает корпус 324 Ball PBGA и шаг между его выводами в 1мм (мы еще никак не освоили такие конструктивы, рискованно). Подошел бы такой же chip, но с корпусом TQFP.

[Ledol]

К Victor®, спасибо за ссылку на Zarlink!
Мы работаем с их продукцией, но эту схему проглядел.
Информация новая и интересная (как раз требуется добавить функцию VLAN и Ethernet 10/100). Огорчает корпус 324 Ball PBGA и шаг между его выводами в 1мм (мы еще никак не освоили такие конструктивы, рискованно). Подошел бы такой же chip, но с корпусом TQFP.

ADM6993
- реально работает в схеме
- цена в 15 раз меньше
- гибкий HDLC режим (любая частота с любой скважностью) по TDM(PCM)
- hardware (или)и sowtfare settings (TWI) включая VLAN по портам и тегам.

[zltigo]

ADM6993

Ага. И ADM6996 тоже.

Эскизы прикрепленных изображений

 

[Ledol]

ADM6993

Ага. И ADM6996 тоже.

Ого. Привет от Галиос-а? А не пробовали это изделие с CISCO стыковать( ADM6996(HDLC) -> G703 <-> G703 -> CISCO)?

[Shamil]

ADM6993
- реально работает в схеме
- цена в 15 раз меньше
- гибкий HDLC режим (любая частота с любой скважностью) по TDM(PCM)
- hardware (или)и sowtfare settings (TWI) включая VLAN по портам и тегам.

Эх, ей бы еще индустриальный диапазон рабочей температуры,
цены б ей не было, для наших приложений.

[Dainis]

ADM6993
- реально работает в схеме
- цена в 15 раз меньше
- гибкий HDLC режим (любая частота с любой скважностью) по TDM(PCM)
- hardware (или)и sowtfare settings (TWI) включая VLAN по портам и тегам.

Эх, ей бы еще индустриальный диапазон рабочей температуры,
цены б ей не было, для наших приложений.

После 2 годичново мученеи с ADM6993 и ADM6996F я откзалсь от ных:
1) Нормально неработает пры HDLC скоростях выше 10Mbit при гапированном клоке.
2) Достаточно сыльно греется.
3) Маленкие RAM вуфера на чипе.

[zltigo]

Ого. Привет от Галиос-а?

Да. Результат консенсуса.

А не пробовали это изделие с CISCO стыковать( ADM6996(HDLC) -> G703 <-> G703 -> CISCO)?

Не обещано :-)

[Волощенко]

ADM6993

Ага. И ADM6996 тоже.

Очень хорошо!!!
А как с реальным КПЗ - коэффициентом полезного заполнения? Отношение скорости PayLoad к пропускной способности канала в процентах (лучше придумать у меня не получилось) , надо же сравниться...
Может, Ledol, и Вы дополните этот микро вернисаж фотографией...

[Ledol]

ADM6993

Ага. И ADM6996 тоже.

Очень хорошо!!!
А как с реальным КПЗ - коэффициентом полезного заполнения? Отношение скорости PayLoad к пропускной способности канала в процентах (лучше придумать у меня не получилось) , надо же сравниться...
Может, Ledol, и Вы дополните этот микро вернисаж фотографией...

Постараюсь в ближайшее время. По поводу скоростей больше 10М пока ничего сказать не могу(VDSL только в перспективе). По КПЗ на данный момент могу сказать следующее:
Проводили сравнительный тест м-у RJ-17 и ADM6993 (предыдущее и новое решение). По ping -l .. -n.. -t .. на длинах пакетов до нескольких килобайт различия не обнаружено(ADM в реж. 10М). При копировании файлов в FARe так же разницы не увидел. Т.Е. скорость всегда опр. канальным уровнем (192-5686 Кб\с).

[Victor®]

Вот еще интересные чипы
http://www.mindspeed.com/web/product/category.html?id=731

И вот что на них делают:
 POTS48_Demo_Board_Fact_Sheet_Final__2_.pdf ( 482.79 килобайт ) Кол-во скачиваний: 1769

[Harbour]

Особенное веселье с их доставанием через некоего г-на Вороненко

[Victor®]

Особенное веселье с их доставанием через некоего г-на Вороненко

CODICO?

[Harbour]

Особенное веселье с их доставанием через некоего г-на Вороненко

CODICO?

Да, оно самое. Может другим повезет, у нас только обещания ;(

[Волощенко]

Добрый день!
Опять нужен совет. Стоит необходимость создания аналогичного конвертора Ethernet10/100-TDM, но для работы еще с пакетами VLAN. Руководство настаивает на собственной разработке с использованием ADM6993/X "HDLC to Fast Ethernet Converter" от Infineon. Документации на него у меня мало, есть только - Data Sheet, Rev 1.11, Nov. 2005. Более ничего не нашел, а описание там все же слабое.
1. Кто-то использовал этот чип, с ним можно управиться?
2. Есть ли на него еще более подробная документация?
3. Есть ли все же альтернативные, заведомо лучшие и опробованные Вами, другие чипы для VLAN?
Спасибо за ответ.

[Vit1248]

1. Кто-то использовал этот чип, с ним можно управиться?
2. Есть ли на него еще более подробная документация?

1. Кто-то использовал, про это тут писали, и меня смущает фраза "Маленкие RAM вуфера на чипе." - не пойму сколько для такого решения надо?
2. Есть еще errata - но там ниче полезного.

[Волощенко]

1. Кто-то использовал, про это тут писали, и меня смущает фраза "Маленькие RAM буфера на чипе." - не пойму сколько для такого решения надо?
2. Есть еще errata - но там ничего полезного.

1. Фраза не моя, но чем больше, тем лучше, особенно если применяется в Ethernet-мосте, и пакеты следуют без перерыва. Кстати, в CS8900A один общий RAM-буфер на 4к (а в ADM6993/X один буфер 6к*64бит).
2. Действительно мало КД на ADM6993/X - начинать что-то делать рискованно.

Мне подсказал iosifk обратить внимание на KSZ8842 от Micrel. Оказалось, что это почти полный функциональный аналог предыдущего чипа, но доступной документации здесь в несколько раз больше. И буферов в нем уже два по 4к каждый, для приема и выдачи. Но механизм управления ими не совсем прозрачен. Собираюсь освоить KSZ8842, для работы с 8-разрядной ISA-шиной.
Кто-то уже работал с KSZ8842? Есть ли особенности применения?

[Vit1248]

[quote name='Волощенко' date='Nov 3 2006, 15:59' post='172119']
[quote name='Vit1248' post='172085' date='Nov 3 2006, 14:53']
По буферам:
KSZ8842: The switching engine has a 32KB internal frame buffer. This resource is shared between all the ports.
ADM6993/X: Built-in data buffer 6Kx64bit SRAM. - это 48КВ - больше чем у micrel-a...

[Ledol]

В теме "Вопрос по микросхеме ADM6993" выложил электричку на китайскую демоплату. В принципе для запуска свича в харде на default установках этого (+datasheet) было достаточно. До управляемости по VLAN и QoS только добрался. Пока вопросов нет.

[Hedgehog in the ...]

Уважаемый All!

Увидел. что в этой теме люди реально работали с ADM6996. Есть вопрос от неофита.
Мне досталась в наследство от уволившегося сотрудника незаконченная разработка - бридж E1-Ethrnet с поддержкой VLAN. Причем бридж является модулем гибкого мультиплексора, поэтому в нем заложена работа на внутренюю шину со скоростью nx64 кбит, а также конфигурирование и управление по оригинальной (proprietary) шине, через RS-485 и через RS-232. Это волшебное устройство собрано на свитче ADM6996M, Ethrnet-маппере DS33Z11 с буферным SDRAM на 128Mbyte. Фреймер сделан на FPGA SPARTAN2E, а для руления всем этим использован ARM7 от STMicroelectronic на частоте 32 МГц.
Я должен вдохнуть жизнь в эту уже проданную железяку. Пришлось изучать VHDL, EWARM от IAR, спаять Wiggler...

Однако сейчас столкнулся с затыком. При подаче сброса от менеджера питания на вход RC свитча никак не удается заставить его обращаться к конфигурационной EEPROM через вывод EECS. Зато, если припаять ко входу RC резистор на +3.3В, все вполне успешно обращается.

Теперь вопрос: значит ли это, что полный Reset ADM6996M через ножку RC невозможен, и при зависании свитча, его будет нельзя перезапустить, не снимая питания? Если вопросов мало - завтра придумаю еще.

С уважением, Александр.

[Волощенко]

Мы вот сделали еще один Ethernet-мост для наших SHDSL-модемов. В отличие от предыдущего, он работает с 10 и 100 Мб/c, а также имеет возможность что-то делать с пакетами VLAN (микросхема CS8900A это не могла).
В качестве контроллера Ethernet использован чип от Micrel KSZ8842-16 MQL. В состав платы также входят C8051F123 и XC9572XL.
Особая благодарность iosifk, который обеспечил документацией, примерами и софтом, где-то на 50Мбайт, консультировал, а, также, не колеблясь, предоставил первый бесплатный образец KSZ8842-16 MQL.

Эскизы прикрепленных изображений

 

[Батька]

Есть ли у кого примеры структурных схем соединения МК и CS8900 A-H?

[Волощенко]

Есть ли у кого примеры структурных схем соединения МК и CS8900 A-H?

В приложении принципиальная схема, там CS8900, C8051F127 и XC9572LX. Все это модуль для передачи Ethernet-10 через каналы E1 или SHDSL, реализованный мною в 2006 г. Кстати, его фото в посте номер 31 этой темы. Этот модуль подключается к соответствующему линейному модему.
Был еще аналогичный проект для подобных задач, но на KSZ8842. Его фото чуть выше.
Высылаю эту схему, как пример использования CS8900. Открыть можно в PCAD или в P-CAD 2006 Schjematiс Viewer.
Удачи.

Прикрепленные файлы

 Shdsl_Eth.sch ( 479.99 килобайт ) Кол-во скачиваний: 40