Jump to content
Калькуляторы

Trango GigaLINK продающие или использующие есть?

Вобщем являюсь несчастным пользователем этого говна. Говна - т.к. заманался писать в их саппорт, и получать глупые отмазки, как будто я купил не железку за 14к с лицензией на 312Mbps в 5к, а Длинк за 40 баксов.

 

Суть проблемы в том, что линк теряет пакеты. В своей сети я привык контролировать каждый пакет. А на двух линках, где присутствует транго, я их постоянно теряю. Я уже весь на говно изошел, и сменил все небрендовые свитчи на брендовые, греша на них. Они конечно доставляли мне неприятности, но как оказалось не они причина.

Вобщем все стрелки сошлись на Транго. Пишу письма в саппорт, меня просят привести "стандартные данные" со статистикой FER, BER, RSSI и т.п. и конечно конфиг. Задают тупые вопросы про заземление, ферритовые фильтры, качество ethernet кабеля и т.п. Тупые - т.к. я до этого им разжевал, что я прекрасно умею пользоваться кабельным тестером, в том числе встроенным цисковским, и кабеля я пробовал самые разнообразные, в т.ч. заэкранированную 6-ю категорию с "крутой железки". Вобщем когда они видели, что в статистике пусто они мне предлагали попробовать новую прошивку. Т.к. процедура тестирования новой прошивки у меня достаточно длительная, чтоб исключить сбой моего оборудования из-за изменений в каком-то их протоколе, то они удачно от меня отпихивались два месяца.

В последнюю неделю нагрузка выросла на одном из линков до 210-240 Mbit, и пакетлосс вырос до 2-3%. Написав очередное письмо, что ваша очередная прошивка не помогла, и не пытайтесь мне впарить очередную без обьяснений, в чем проблема, они предложили мне заполнить длинную форму, где разве что не нужно указать цвет волос на моей заднице.

В горе, я расколупал софтово и без изменений того самого софта, чтоб не потерять гарантию, их железяку, которая представляет из себя линукс в ARM платке (IXP проц), броадкомовский 5-и портовый свитч (4 порта на передней панели и 1 порт на FPGA), FPGA который хавает езернет и как-то формирует уже нужный RF. При тестировании, обнаружил, что железка очень любит модифицировать байт равный 0x55. Т.е. скажем если у пинга pattern состоит из всего набора символов - наверняка пострадает 0x55. Чаще всего он чудесным образом изменяется на 0x54 или 0x56. Попробовал отправить пинг состоящий из сплошных 0x55 - его потери увеличись раза в два. Ломал голову над тем, почему 0x55 наверное день. Потом дошло... "55 55 55 55 55 55 55 D5". Ethernet preamble.

 

Вобщем не знаю какой национальности у них программер который писал код для FPGA, но похоже поиск преамбулы у них сделан престранно. Если сделать на малозагруженном(30-50 Мбит) линке пинг - потери около 0.1%-0.2%. Если паттерн поменять на "55 55 55 55 55 55 55 D5" - потери составят 30%-50%. Написал им письмо. Но чую жопой, что их отмороженный саппорт посчитает меня "шибко умным" и в очередной раз отфутболит.

В огорчении, что наша контора успела купить этот говнопродукт в кол-ве 3-х пар, если они так поступят, мне останется только зарядить человека строчить данную историю на все форумы и сайты, русскоязычные и забугорные, что Транго продукты - *ОВНО, с изложением доказательств. Посмотрю я на их продажи, после такого. А что еще делать?

 

Заберу слово "говно" обратно и потру пост, если этот продукт начнет нормально работать и они исправят баг.

Ваши мысли что делать?

Share this post


Link to post
Share on other sites

Скажите, а какого ответа Вы ожидали от поддержки, в ситуации, когда им говорят:

"Всё настроено правильно, только пакеты теряются. Почему?"

Если посмотреть с "их" стороны, то такая инфа-на уровне "подземный стук в подполе".

Вот саппорт звонит программеру, говорит - так и так, пакеты теряются. И больше никакой подсказки. Что он может сказать? Только надолго задуматься.

 

Касательно стандартных вопросов и советов проверить кабель итп. - Квалификацию спрашивающего еще надо уметь увидеть. А если ты сам не супер-спец (а кто таких на саппорт посадит, кто из таких туда пойти захочет? - они в другом месте полезней) то разницы между реальным спецом, который говорит "у меня все ок" и просто самоуверенным "всезнайкой" - разглядеть сложно. Да и хорошие спецы иногда забывают что-то. Хотя я вашего разговора не видел, просто делаю предположения.

 

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

 

При появлении доп. инфы (Пропадания при большой нагрузке) должны начаться попытки повторить баг в лаборатории. Тут конечно вежливым было бы сообщить "мы пытаемся повторить проблему".

 

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

 

А Вы как считаете, на каком этапе их саппорт действовал неверно? Как должен был действовать? Если исправят баг, что должны предпринять (извиниться, спасибо в release notes добавить)?

 

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

 

 

А если этот исправят, а через 3 месяца еще один баг найдется - снова станут тем самым?

Или вот Вы везде расскажете, какие они нехорошие, предположим продажи у них упадут ниже плинтуса, и тут вдруг через пару недель они дотумкают, как баг исправить. Будете опровержения писать :) ?

Edited by dmp

Share this post


Link to post
Share on other sites

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

Они привыкли, что запрашивают стандартную инфу, и что они там находят хреновый MSE (Mean Square errors) или BER или сигнал(rssi), и советуют подстроить антенну. Запрашивают ее у меня. Я ее отправляю. Но т.к. показатели у меня отличные, их "программа" на этом заканчивается. Попыток разрешить нештатную ситуацию просто нет. Просто "попробуйте обновить прошивку, если у вас не получается, обращайтесь к нам". Все.

 

Я проработал достаточно долго в саппорте в начале своей карьеры, и хорошо знаю, что есть два варианта работы саппорта.

"Уставший" саппорт, к которому обращаются постоянно по глупым вопросам типа "интернета нет", который уже выработал стереотипы в мозгу, и начинает спрашивать типичные вопросы "подключен ли ваш комп к электричеству". Еще они знают, что если клиент умничает, то в большинстве случаев просто это понты, а на самом деле он наколупал где-то в "галочках что-то". Поэтому чаще всего саппорт динамит клиента как может. Особенно часто такое с саппортом на "дешевых" продуктах, типа физиков на супермегабитном тарифе за 10 баксов, или при продаже "длинк роутера" за 40 баксов.

 

И как надо работать, это когда рассматриваешь каждого клиента внимательно, независимо от того, насколько он выглядит глупым. Если клиент платил мне по 14 килобаксов за железку, и возможно заплатит еще, я бы облизывал его и отвечал как можно скорее. Если клиент "пропал" после очередного письма, у меня висит тикет, проблема серьезная, я продолжаю интересоваться, решилась бы проблема. И клиенты обычно хранятся в БД, чтоб при очередном обращении, посмотреть историю предыдущих, и не задавать вопросы, на которые у меня уже есть ответы, чем кстати тоже страдает транговский саппорт.

 

Кроме того, когда мне присылают формочку в формате "какой-то там Microsoft Word", которого у меня на компе в помине не было, у меня это вызывает тихое бешенство. Т.к. во первых мне прийдется заниматься поиском винды с этим вордом, во вторых угрохать кучу времени на заполнение данных, т.к. она попросту неудобна. Ну еще и форматированием вывода команд, при упихивании в форму. C учетом того, что вывод некоторых команд многостраничен, это очень нудное и тратящее время занятие.

 

Первое что я сделал работая саппортом - написал при обращении в саппорт веб-форму, с минимально необходимым количеством данных.

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

 

У транго этого и в помине нет, и то, что они "по старинке", "выскребают по крупинке", без тикетов, по e-mail, нужную информацию, присылают вордовские файлы. когда время работы саппорта попросту не обозначено на сайте - это говорит о крайне плохой организации техсаппорта.

 

Говном они перестанут быть, если наладят нормальную техподдержку и исправят _критический_ баг. Фактически я был вынужден сам разобраться в структуре их продукта (железа и ПО), и найти, на каком этапе у них баг. Обычно я такую работу выполняю платно, и за солидные деньги. И меня крайне раздражает, если кто-то впустую тратит мое время, и это связано с дорогостоящим продуктом, который должен работать как часы. И когда баг таков, что должен был быть отловлен еще на этапе разработки.

 

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

А багов там дохрена, и никто особо не шевелится их исправлять. Вот например только что. Меняю скорость, по мануалу, она должна меняться только после ребута, но по факту она меняется сразу, но чтоб выполнить условие мануала о ребуте - сохраняю настройки и выполняю ребут. Один юнит ребутается нормально, а второй... вуаля, теряет настройки скорости вообще. Это продукт за 14 килобаксов? Ой-ляля.

 

(trango-config)# speed 5 qam256
symrate:        46.00
modulation:     256QAM
speed:          312.20
bpf:            56
bandwidth:      56/80
SUCCESS
(trango-config)# save
New configuration saved

SUCCESS
(trango-config)# rebootConnection closed by foreign host.

подождал

/system telnet 10.22.22.5
Trying 10.22.22.5...
Connected to 10.22.22.5.
Escape character is '^]'.
trango login: admin
Password:


Trango Broadband Wireless:  TrangoLINK Giga Command Line Interface v2.3.8

(trango-view)# conf
Password:
(trango-config)# power
Power: 5.0 dBm
(trango-config)# speed
symrate:        0.000000
modulation:     none
speed:          0.000000
bpf:            0
bandwidth:      0
(trango-config)#

 

Share this post


Link to post
Share on other sites

Спасибо, ответы исчерпывающие.

 

А что взяли сразу 3 линка ? Не ожидали такого за подобные деньги ? Или сначала взяли один на тест, и проблем не проявилось ?

 

Насчёт что делать - не имею соответствющего опыта для дельного совета, так что просто мысли вслух:

 

Если баг не исправится, то вроде как продукт не соответствует спецификации. Требовать возврата денег :) Проводить экспертизу, подавать в суд...

 

Можно попытаться загнать буржуям (например тут: http://www.dslreports.com/forum/r21508512-...Sale-or-Wanted) некоторые из них транго любят, и на такие "мелочи" могут внимания не обращать.

Share this post


Link to post
Share on other sites

3 линка - т.к. сразу нужно было решение на два линка, и один комплект резервный. Нашару на тест нам их никто не дал бы, а брать один комплект "на тест" - это выкинуть $14k из оборота. Эксплуатировать такой линк нельзя, т.к. нет резерва.

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

Проблемы проявились не сразу, а с ростом нагрузки.

 

Share this post


Link to post
Share on other sites

 

мои знакомые такую штуку ставили, все проблемы вылазили на мелких пакетах, у них эта штука между провайдером и "хомяками" стояла, заметили все проблемы начинались когда "хомяки" начинали по вечерам в линию играть, трафик никакой, а ошибок море, умудрились они эту штуку продать, в ближайшее зарубежье, с монтажём, и перекрестились

Share this post


Link to post
Share on other sites
Вобщем являюсь несчастным пользователем этого говна. Говна - т.к. заманался писать в их саппорт, и получать глупые отмазки, как будто я купил не железку за 14к с лицензией на 312Mbps в 5к, а Длинк за 40 баксов.

 

хех, быстро у тя любовь к ним кончилась. А ведь так хвалил...

Share this post


Link to post
Share on other sites

sfstudio - на малых нагрузках все хорошо было... урок блин неплохой. Обжегся неслабо.

 

Сегодня пришел ответ, через неделю обещают новый код FPGA.

Share this post


Link to post
Share on other sites

Ага, они написали что протестировали, и у них все хорошо.

Просят сделать скриншот с sysinfo... недоверчивые м%я. Хотя я им уже присылал его в текстовом виде.

Сделал 16 скриншотов цисковских свитчей с которых пингую, sysinfo и прочего. Пусть подавятся.

Share this post


Link to post
Share on other sites

Пригласите их к вам приехать...

т.с. для шеф-контроля..

Share this post


Link to post
Share on other sites

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

То, что преамбула распознается в середине пакета говорит о том, что Gigabit MAC controller сделан на FPGA программно, и отжирает львиную долю ресурсов. Это кроме того, что его еще нужно правильно реализовать. Вообще, это по сути ошибка аппаратного дизайна, потому как чип стоит копейки.

 

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

Как итог в фрейме не проверяют размер пакета (передан ли предыдущий пакет), и полностью pattern preamble,если потери увеличиваются от 0x55, и от 0x55D5 - они равны потерям если паттерн - полная преамбула.

 

Они шефу так мозги промыли, что даже я засомневался в своих выводах. Пришлось угрохать еще 3 часа, убрать транк с портов, и сделать порты с обоих сторон в access режиме.

 

Выглядит это так:

cisco_switch_rack_2#ping 10.22.22.77 data 55D5 validate repeat 100 size 1400

Type escape sequence to abort.
Sending 100, 1400-byte ICMP Echos to 10.22.22.77, timeout is 2 seconds:
Packet has data pattern 0x55D5
Reply data will be validated
!!!!..!!.!!!!.....!......!!.!!...!....!!!!...!..!!!..!..!!..!!!.!!!.!!
!!..!.!.!!!!.!!..!.....!.!!..!
Success rate is 50 percent (50/100), round-trip min/avg/max = 1/1/9 ms
cisco_switch_rack_2#ping 10.22.22.77 data FFFF validate repeat 100 size 1400

Type escape sequence to abort.
Sending 100, 1400-byte ICMP Echos to 10.22.22.77, timeout is 2 seconds:
Packet has data pattern 0xFFFF
Reply data will be validated
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/2/9 ms
cisco_switch_rack_2#ping 10.22.22.77 data ABCD validate repeat 100 size 1400

Type escape sequence to abort.
Sending 100, 1400-byte ICMP Echos to 10.22.22.77, timeout is 2 seconds:
Reply data will be validated
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/2/9 ms
cisco_switch_rack_2#ping 10.22.22.77 data 0000 validate repeat 100 size 1400

Type escape sequence to abort.
Sending 100, 1400-byte ICMP Echos to 10.22.22.77, timeout is 2 seconds:
Packet has data pattern 0x0000
Reply data will be validated
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/2/9 ms

Забавно, правда?

 

 

Share this post


Link to post
Share on other sites
Мне очень сильно кажется, что их задача наврать с три короба, чтоб не допустить возврата денег.

То, что преамбула распознается в середине пакета говорит о том, что Gigabit MAC controller сделан на FPGA программно, и отжирает львиную долю ресурсов. Это кроме того, что его еще нужно правильно реализовать. Вообще, это по сути ошибка аппаратного дизайна, потому как чип стоит копейки.

 

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

Как итог в фрейме не проверяют размер пакета (передан ли предыдущий пакет), и полностью pattern preamble,если потери увеличиваются от 0x55, и от 0x55D5 - они равны потерям если паттерн - полная преамбула.

 

Они шефу так мозги промыли, что даже я засомневался в своих выводах. Пришлось угрохать еще 3 часа, убрать транк с портов, и сделать порты с обоих сторон в access режиме.

 

Выглядит это так:

cisco_switch_rack_2#ping 10.22.22.77 data 55D5 validate repeat 100 size 1400

Type escape sequence to abort.
Sending 100, 1400-byte ICMP Echos to 10.22.22.77, timeout is 2 seconds:
Packet has data pattern 0x55D5
Reply data will be validated
!!!!..!!.!!!!.....!......!!.!!...!....!!!!...!..!!!..!..!!..!!!.!!!.!!
!!..!.!.!!!!.!!..!.....!.!!..!
Success rate is 50 percent (50/100), round-trip min/avg/max = 1/1/9 ms
cisco_switch_rack_2#ping 10.22.22.77 data FFFF validate repeat 100 size 1400

Type escape sequence to abort.
Sending 100, 1400-byte ICMP Echos to 10.22.22.77, timeout is 2 seconds:
Packet has data pattern 0xFFFF
Reply data will be validated
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/2/9 ms
cisco_switch_rack_2#ping 10.22.22.77 data ABCD validate repeat 100 size 1400

Type escape sequence to abort.
Sending 100, 1400-byte ICMP Echos to 10.22.22.77, timeout is 2 seconds:
Reply data will be validated
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/2/9 ms
cisco_switch_rack_2#ping 10.22.22.77 data 0000 validate repeat 100 size 1400

Type escape sequence to abort.
Sending 100, 1400-byte ICMP Echos to 10.22.22.77, timeout is 2 seconds:
Packet has data pattern 0x0000
Reply data will be validated
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/2/9 ms

Забавно, правда?

По обоим сторонам стоят циски?

 

Была схожая проблема, при такой схеме роутер --- каталист --- радиолинк --- каталист. Шел пакетлосс до 5% большую часть времени, иногда пропадал не несколько часов. В статистике роутера и свичей, никаких ошибок не было. Причины данного явления так установить не удалось. Оборудование пробовалось разное (Длинк, ББ, Аперто), проблема решилась сама по себе когда один из каталистов заменили на нортеловский свич.

Share this post


Link to post
Share on other sites

До этого вместо каталиста стоял с одной стороны linksys. Причем меняли две разные модели линксиса.

Через этот же каталист ходит куча другого железа, и нигде таких потерь нет.

Кроме того обратите внимание, сейчас нагрузка невелика, потерь почти не видно (скорее всего они будут около 0.5%), но наличие паттерна 55D5 в пинге создает почти 50% потерь.

Share this post


Link to post
Share on other sites

Нашел точную закономерность. Проблема появляется четко при увеличении спектра более 40 Mhz.

Если 40 Mhz - потерь нет.

Буду прессовать их дальше.

Share this post


Link to post
Share on other sites

Попробуйте написать гневное письмо прямо высшему руководству компании. Например, Zdravko Divjak, president and CEO of Trango Systems, Inc и еще бы копию вице-президенту по продажам. Иногда помогает. Заодно посмотрите как у них работает "властная вертикаль".

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this