Перейти до

UA.PON v6.0


wladd

Рекомендованные сообщения

как бы 7у.е это 150грн на 10 подключках 1500грн экономии.... поключили 20 абонов и заработали + до зп 3к грн

а свистопляски - поначалу и с бдкомом было тоже немало

 

Полностью согласен. Сейчас время не спокойное и каждая копейка на счету. Так что немного подождите и мы разберёмся с Форой.

На текущий момент китайцы прислали новую прошивку, которая решает проблему Opt 82. Тестирую...

Ссылка на сообщение
Поделиться на других сайтах
  • Відповіді 1k
  • Створено
  • Остання відповідь

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

мне по фиг, как оно называеться, главное настроить чтобы wi-fi отдавал!!!!

я конечно понимаю, что у айсилайн немного "подгорает" от цены пикотела, но зачем же так активно это показывать?

Я наверное странный - но не шьем ни ONU, ни OLT. Работает с заводским софтом пару лет, никто туда и не лазит лишний раз.

Posted Images

Прошивку проверил. Всё пофикшгено. Опция добавляется. Remote ID и Circuit ID нужную информацию показываю. К сожалению, данная прошивка не является даже бета релизом, а сделана, как говорится, на коленках, поэтому в массы пока не пойдёт - я её у себя придержу. Как торлько появится нормальная версия прошивки, выложу её на наш дроп и отпишусь

Відредаговано Reanemator_ua
Ссылка на сообщение
Поделиться на других сайтах

Немножко оффтопа. Если кто всречал подобную ошибку epon sla set failed,epon_sla_if,3226!

Ошибка редкая, но означает она буквально следующее - суммарно ваши ОНУшки потребляют полосы пропускания больше, чем может выдать ОЛТ. Допустим, у Вас в ветке 64 ОНУ и на каждой настроен SLA с CIRом 15 mbps. Умножим 15 на 64 получаем, что ОЛТ гарантирует суммарную пропускную способность не меньше 960 mbps. Но проблема в том, что ОЛТ может гарантировать только около 950 mbps, остальное - служебный трафик. Таким образом, если у вас дерево забито до отказа и вы любитель использовать SLA, то ставьте CIR не 15000 kbps, а немного поменьше.

Ссылка на сообщение
Поделиться на других сайтах

Немножко оффтопа. Если кто всречал подобную ошибку epon sla set failed,epon_sla_if,3226!

Ошибка редкая, но означает она буквально следующее - суммарно ваши ОНУшки потребляют полосы пропускания больше, чем может выдать ОЛТ. Допустим, у Вас в ветке 64 ОНУ и на каждой настроен SLA с CIRом 15 mbps. Умножим 15 на 64 получаем, что ОЛТ гарантирует суммарную пропускную способность не меньше 960 mbps. Но проблема в том, что ОЛТ может гарантировать только около 950 mbps, остальное - служебный трафик. Таким образом, если у вас дерево забито до отказа и вы любитель использовать SLA, то ставьте CIR не 15000 kbps, а немного поменьше.

попадался уже

ставил всегда раньше тариф 30 мбит как 

epon sla upstream pir 30760 cir 30760
epon sla downstream pir 30760 cir 30760
 
после 31-ой ону на ветке начали отваливаться ону с перерегистрацией
теперь описываю так
epon sla upstream pir 30760 cir 10240
 epon sla downstream pir 30760 cir 10240
 
не давать зарегистрироваться ону - странный механизм обработки ошибки
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

 

Немножко оффтопа. Если кто всречал подобную ошибку epon sla set failed,epon_sla_if,3226!

Ошибка редкая, но означает она буквально следующее - суммарно ваши ОНУшки потребляют полосы пропускания больше, чем может выдать ОЛТ. Допустим, у Вас в ветке 64 ОНУ и на каждой настроен SLA с CIRом 15 mbps. Умножим 15 на 64 получаем, что ОЛТ гарантирует суммарную пропускную способность не меньше 960 mbps. Но проблема в том, что ОЛТ может гарантировать только около 950 mbps, остальное - служебный трафик. Таким образом, если у вас дерево забито до отказа и вы любитель использовать SLA, то ставьте CIR не 15000 kbps, а немного поменьше.

попадался уже

ставил всегда раньше тариф 30 мбит как 

epon sla upstream pir 30760 cir 30760
epon sla downstream pir 30760 cir 30760
 
после 31-ой ону на ветке начали отваливаться ону с перерегистрацией
теперь описываю так
epon sla upstream pir 30760 cir 10240
 epon sla downstream pir 30760 cir 10240
 
не давать зарегистрироваться ону - странный механизм обработки ошибки

 

А вот это очень инетерсно!

Получается что ОНУ можето отваливаться в перерегистрацию в случае превышения CIR

Это требует проверки!!!

 

- у нас на стендах ни одного отвала за сутки. Может эти магические пере-регистрации связаны именно с превышением полосы?

 

Screep - расскажите, а у вас какие полосы CIR назначены на каждую ОНУ и сколько их в дереве?

Відредаговано wladd
Ссылка на сообщение
Поделиться на других сайтах

 

 

Немножко оффтопа. Если кто всречал подобную ошибку epon sla set failed,epon_sla_if,3226!

Ошибка редкая, но означает она буквально следующее - суммарно ваши ОНУшки потребляют полосы пропускания больше, чем может выдать ОЛТ. Допустим, у Вас в ветке 64 ОНУ и на каждой настроен SLA с CIRом 15 mbps. Умножим 15 на 64 получаем, что ОЛТ гарантирует суммарную пропускную способность не меньше 960 mbps. Но проблема в том, что ОЛТ может гарантировать только около 950 mbps, остальное - служебный трафик. Таким образом, если у вас дерево забито до отказа и вы любитель использовать SLA, то ставьте CIR не 15000 kbps, а немного поменьше.

попадался уже

ставил всегда раньше тариф 30 мбит как 

epon sla upstream pir 30760 cir 30760
epon sla downstream pir 30760 cir 30760
 
после 31-ой ону на ветке начали отваливаться ону с перерегистрацией
теперь описываю так
epon sla upstream pir 30760 cir 10240
 epon sla downstream pir 30760 cir 10240
 
не давать зарегистрироваться ону - странный механизм обработки ошибки

 

А вот это очень инетерсно!

Получается что ОНУ можето отваливаться в перерегистрацию в случае превышения CIR

Это требует проверки!!!

 

- у нас на стендах ни одного отвала за сутки. Может эти магические пере-регистрации связаны именно с превышением полосы?

 

Screep - расскажите, а у вас какие полосы CIR назначены на каждую ОНУ и сколько их в дереве?

 

может быть я не правильно выразился

звонит клиент и жалуется что нет интернетов

на ону пон порт мигает зеленым (онушни тогда еще были 1004В) - значит идет регистрация

смотрю логи, а оно его реконектит каждую секунду

ону цепляется, доходит до применения sla, вылетает с ошибкой и дисконектится... и так по кругу

начал рыть логи - оказывается такое было уже накануне несколько раз, но никто не жаловался

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

Відредаговано Den_LocalNet
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

если внимательно прочесть переписку - обсуждение того что тут было

унас есть два прецедента

 

Водном случае, человек наблдал отвал онушки после (но не значит вследствие)

того как наблдал не выдачу ДДМ.

 

параметры CIR/PIR - не проверены

 

В другом случае, человек наблдал не отдачу ДДМ, но отвал не наблюдал.

параметры CIR/PIR проверены

epon onu-config-template t2318
 cmd-sequence 1 epon sla upstream pir 1000000 cir 512
 cmd-sequence 2 epon sla downstream pir 1000000 cir 512

Всего около 35 ОНУ на ветке.

Мы собрали два стенда

 

КНР -  более 40 ОНУ NA-1001B  -нет отвалов ( да и ДДМ показывает больше суток)

Тута - 30*1501С + 10*NA-1001 + 2*NA-1001B  -не отвалов да и ДДМ показывает исправно

 

Версия:

Эпизод отваливающеся ОНУ может быть связан с превышемем CIR (напремер)

 

 

Тов Screep - пришлите ваши даные CIR/PIR и количество ОНУ.

 

Это конечно только версия, но мы так и ли иначе из гностических

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

Відредаговано wladd
Ссылка на сообщение
Поделиться на других сайтах

если внимательно прочесть переписку - обсуждение того что тут было

унас есть два прецедента

 

Водном случае, человек наблдал отвал онушки после (но не значит вследствие)

того как наблдал не выдачу ДДМ.

 

параметры CIR/PIR - не проверены

 

В другом случае, человек наблдал не отдачу ДДМ, но отвал не наблюдал.

параметры CIR/PIR проверены

epon onu-config-template t2318
 cmd-sequence 1 epon sla upstream pir 1000000 cir 512
 cmd-sequence 2 epon sla downstream pir 1000000 cir 512

Всего около 35 ОНУ на ветке.

Мы собрали два стенда

 

КНР -  более 40 ОНУ NA-1001B  -нет отвалов ( да и ДДМ показывает больше суток)

Тута - 30*1501С + 10*NA-1001 + 2*NA-1001B  -не отвалов да и ДДМ показывает исправно

 

Версия:

Эпизод отваливающеся ОНУ может быть связан с превышемем CIR (напремер)

 

 

Тов Screep - пришлите ваши даные CIR/PIR и количество ОНУ.

 

Это конечно только версия, но мы так и ли иначе из гностических

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

 

На тій лінії, було 9 ону зареєстровано CIR/PIR 100000/15000 так десята викидала такі фортеля, правда ону бдком аніак та 1 шт фора.

 

На іншій голові все так само тільки онушок було 17 шт з такими ж параметрами CIR/PIR так все працює нормально 

 

Зробив там де спостерігався глюк CIR/PIR 100000/10000, ніби зареєструвалась онушка  нормально, буду спостерігати. Але є декілька гілок де64 онушки, мішанка бдком, аніак, фіком, тплінк,  там  CIR/PIR 100000/15000 і всі реєструються, аптайм порядку місяця у всіх де живлення не вимикали. Тому питання - то фора така "фортова"?

 

PS.

ДДМ не віддається (замічено) тоді коли sh ep ac видає

 

a0c6.ec00.fc94 auto_configured linkfault

або

a0c6.ec00.fc98 authenticated   notready

тоді з ону нічого не віддається, хоча трафік якийсь через ню біжить, але швидкість не піднімається більше 1-10мбіт\с і можливі втрати до 10%-15% потім вона рандомно починає перереєстровуватись поки не перезавантажити по живленню.

Відредаговано skreep
Ссылка на сообщение
Поделиться на других сайтах

Я пока не буду делать никаких выводов, но наш стенд из 64 ONU стоит уже 2 дня. никаких дерегистраций не происходит. Я выключал DBA совсем, ставил Cycle-time на 25000 и 50000, ставил динамический Cycle-time - всё работает.

 

Правда было замечено что при фиксированном Cycle-time 25000 TQ скорость от ОНУ в сторону ОЛТа не превышает 460 мбит/с. При установке динамического времени цикла скорость подпрыгнула до вполне нормальных 780 мбит/с.

 

Так или иначе, я дерегистрировал Форы и заново регистрировал, сбрасывал конфиг ЕПОН порта, чтобы все ОНУ одновременно зарегались. При этом регистрация 64 ОНУ проходит секунд за 30, при том что пластиковые, что металлические ФОРЫ регистрируются не последними, а мелькают среди BDCOM-ов. Это говорит, что с MPCP у них никаких проблем не наблюдается. На ночь поставили IPERF между ПК, подключённого к пластиковой ФОРЕ, и ПК, подключённого к ГЕ порту ОЛТа. В результате 10 часового теста в режиме полного дуплекса ОНУ не отвалилась и выдала вполне симметричную скорость 651/609 мбит/с

 

Мне остаётся только продолжать тест и попробовать ещё больше нагрузить PON чип. Кроме того я ожидаю поступления на наш склад партии пластиковых ФОР - тогда смогу поставить больше ФОР в ветку, убрав часть BDCOM-ов.

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

1. about the de-regist bug, our side didn't repeated yeat. it running > 30 hours, still stable.
it is still hard to tell why the de-regist problem appears, until it repeated.

may be the optical modual problem, which means it is the hardware problem of a specific, standalone device.

 

2. about the opt82, it should be OK, tested in all cases, e.g: tag/untag mode, all works. and we're ready to release you with new firmware.

 

3. What we can report to community now time?

 

1) opt82 problem is solved. 2) we're trying to re-display the bug problem, but no luck. > 30 hours elapsed, still stable,

I  didn't meant our onus of no any statability problems; however as more test time elapsed, higher probability of problems

of standalone/few devices, or even mightbe the OLT optical moduals.

 

if we still couldn't repeat the bug, i guess we need more information of this problem. e.g: in case of it appears, what the

optical power it is?what the probability of this bug? is there any special usage of that device?

did  all devices appended under the same pon port rised the bug? or even could you please recycle the problem device,

and open up the box, so that we can check the circuite board....

 

3. about the ACL, might take more RD resource, the deadline mightbe delay, will be 2-10.

 

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

Відредаговано wladd
Ссылка на сообщение
Поделиться на других сайтах

Спасибо вам большое. Классная книга. Я заказал себе такую, на вашем сайте. Буду ждать, когда приедет. Я в PONE  новенький. Много чего не понимаю. Хочу спроектировать GPON, но пока не понимаю топологию сети и как строят такие сети.

Ссылка на сообщение
Поделиться на других сайтах

В результате 86000 секунд прогона IPERF-ом в режиме FULL-DUPLEX TCP трафика через 2 ONU FORA NA-1001B (2 ПК подключёны к 2 Форам, 2 других - к GE портам ОЛТа), обе ОНУшки стабильно отработали. Суммарная скорость 2 потоков, пропущенных через ОЛТ, - 730/670 mbps. У меня закончились идеи, как можно нагнуть ФОРу и заставить её дерегистрироваться. Разве что дождаться поступления новой партии ФОР и включить в дерево их побольше.

 

Мы так и не собрали статистику. Продано около 1000 ОНУ. Пока мы услышали о проблеме от 2-3 клиентов - это около 10-30 ОНУ. Где все остальные :) ? Неужели ещё не ставили форы "в бой"? 

Ссылка на сообщение
Поделиться на других сайтах

В бой с колес ушло уже 6 штук. Разные ветки, забиты по разному. От 20-ти до 60-ти зарегистрированных ону на пон-порт.

BDCOM P3310B Software, Version 10.1.0B Build 16358
Клиенты только BDCOM (от 1004В до 1501С1). Три дня - полет нормальный.

Вылезла единственная мелкая проблема..

При:

  epon onu port 1 ctc rate-limit 55000 ingress
  epon onu port 1 ctc rate-limit 55000 egress

скорость не режется.

 

Пришлось поправить скрипты в биллинге на:

 epon sla upstream pir 55000 cir 15000
 epon sla downstream pir 55000 cir 15000
Ссылка на сообщение
Поделиться на других сайтах

 

В бой с колес ушло уже 6 штук. Разные ветки, забиты по разному. От 20-ти до 60-ти зарегистрированных ону на пон-порт.

BDCOM P3310B Software, Version 10.1.0B Build 16358

Клиенты только BDCOM (от 1004В до 1501С1). Три дня - полет нормальный.

Вылезла единственная мелкая проблема..

При:

  epon onu port 1 ctc rate-limit 55000 ingress
  epon onu port 1 ctc rate-limit 55000 egress

скорость не режется.

 

Пришлось поправить скрипты в биллинге на:

 epon sla upstream pir 55000 cir 15000
 epon sla downstream pir 55000 cir 15000

 

Ну опять же, я не думал что кто-то будет использовать полисинг на ОНУ. Как правило скорость режут шейпером. Поэтому функцию Rate-Limit на FORЕ я не проверял. Как мне кажется, она там лишняя.

Ссылка на сообщение
Поделиться на других сайтах

 

 

В бой с колес ушло уже 6 штук. Разные ветки, забиты по разному. От 20-ти до 60-ти зарегистрированных ону на пон-порт.

BDCOM P3310B Software, Version 10.1.0B Build 16358

Клиенты только BDCOM (от 1004В до 1501С1). Три дня - полет нормальный.

Вылезла единственная мелкая проблема..

При:

  epon onu port 1 ctc rate-limit 55000 ingress
  epon onu port 1 ctc rate-limit 55000 egress

скорость не режется.

 

Пришлось поправить скрипты в биллинге на:

 epon sla upstream pir 55000 cir 15000
 epon sla downstream pir 55000 cir 15000

 

Ну опять же, я не думал что кто-то будет использовать полисинг на ОНУ. Как правило скорость режут шейпером. Поэтому функцию Rate-Limit на FORЕ я не проверял. Как мне кажется, она там лишняя.

 

А разве вторая конструкция это не полисер тоже?

Я думал что единственная разница в том, что первая конструкция режет скорость на UNI портах, а вторая на EPON порту ОНУ.

Ссылка на сообщение
Поделиться на других сайтах

 

 

В бой с колес ушло уже 6 штук. Разные ветки, забиты по разному. От 20-ти до 60-ти зарегистрированных ону на пон-порт.

BDCOM P3310B Software, Version 10.1.0B Build 16358

Клиенты только BDCOM (от 1004В до 1501С1). Три дня - полет нормальный.

Вылезла единственная мелкая проблема..

При:

  epon onu port 1 ctc rate-limit 55000 ingress
  epon onu port 1 ctc rate-limit 55000 egress

скорость не режется.

 

Пришлось поправить скрипты в биллинге на:

 epon sla upstream pir 55000 cir 15000
 epon sla downstream pir 55000 cir 15000

 

Ну опять же, я не думал что кто-то будет использовать полисинг на ОНУ. Как правило скорость режут шейпером. Поэтому функцию Rate-Limit на FORЕ я не проверял. Как мне кажется, она там лишняя.

 

Ну почему же, если сделать один единственный тариф, допустим 50М за ххх грн., то проще будет обрезать скорость на каждой ОНУ, без включения шейпера. А без шейпера и ресурсов оборудования надо поменьше. Пока я не слышал, что б так делали, ну а дальше посмотрим.

Ссылка на сообщение
Поделиться на других сайтах

Rate-limit - это полисинг, т.е. жёсткое обрезание трафика, ведущее к потерям пакетов. Шейпинг - обрезание трафика более мягкое (с использованием размера TCP окна... если я не прав, поправьте).

Я всегда клиентам говорю, что на ONU есть шейпер, подразумевая SLA. Но на самом деле это никакой не шейпер. SLA определяет, какую пропускную способность (гарантированную (CIR) и пиковую (PIR)) может иметь ONU. Эта информация учитывается на стороне OLT-а при выделении ОНУ квантов времени. Т.е. ОЛТ видит, что у ОНУшки буфер забит и ей необходимо выделить окно большого размера для передачи, но при этом ОНУ уже практически исчерпала значение PIR - в этом случае ОЛТ примет решение о выделении меньшего кванта времени, чем просит ОНУ. В итоге в буфере ОНУ пакеты будут накапливаться до тех пор, пока буфер не переполнится, а как результат - опять потеря пакетов.

Ссылка на сообщение
Поделиться на других сайтах

Новая прошивка для FORA NA-1001B, решающая проблему с Option 82, выложена на дроп https://www.dropbox.com/sh/r35rr8qrh7dxygv/AABZRUkALVmufqJEHD6BmRmya?dl=0.

Напомню, UImage шьём через веб морду, архив jffs2_fs.tar.gz - через CLI OLT-а (как говорится, кому как больше нравится).

Ссылка на сообщение
Поделиться на других сайтах

Rate-limit - это полисинг, т.е. жёсткое обрезание трафика, ведущее к потерям пакетов. Шейпинг - обрезание трафика более мягкое (с использованием размера TCP окна... если я не прав, поправьте).

Нет.

Полисинг тупо дропает пакеты, которые не влазят в rate-limit.

Шейпер же пытается такие пакеты поставить в очередь и затормозить, т.е. таким образом заставить отправителя медленнее отправлять данные. Ну и уже "непослушных" дропает.

 

Вообще - да, шейпер более толерантен к TCP, но глубже ethernet кадров обычно не лезет и сам по себе о TCP (как и о всём остальном) знать не знает.

Відредаговано Abram
Ссылка на сообщение
Поделиться на других сайтах

Rate-limit - это полисинг, т.е. жёсткое обрезание трафика, ведущее к потерям пакетов. Шейпинг - обрезание трафика более мягкое (с использованием размера TCP окна... если я не прав, поправьте).

Я всегда клиентам говорю, что на ONU есть шейпер, подразумевая SLA. Но на самом деле это никакой не шейпер. SLA определяет, какую пропускную способность (гарантированную (CIR) и пиковую (PIR)) может иметь ONU. Эта информация учитывается на стороне OLT-а при выделении ОНУ квантов времени. Т.е. ОЛТ видит, что у ОНУшки буфер забит и ей необходимо выделить окно большого размера для передачи, но при этом ОНУ уже практически исчерпала значение PIR - в этом случае ОЛТ примет решение о выделении меньшего кванта времени, чем просит ОНУ. В итоге в буфере ОНУ пакеты будут накапливаться до тех пор, пока буфер не переполнится, а как результат - опять потеря пакетов.

т.е. как я и говорил:

1. Шейпера на ОНУ нет. Только полисинг.

2. epon onu port 1 ctc rate-limit позволяет резать скорость на UNI портах ОНУ (если у вас 4-х портовая ОНУ - вы сможете резать скорость на каждом порту отдельно, без общего ограничения на EPON порту)

3. epon sla downstream/upstream режет скорость на EPON порту ОНУ (вне зависимости от кол-ва UNI портов и ограничений на них).

    т.е. если применить

    epon sla downstream pir 55000 cir 15000

    и

    epon onu port 1 ctc rate-limit 55000 ingress

    epon onu port 2 ctc rate-limit 55000 ingress

    epon onu port 3 ctc rate-limit 55000 ingress

    epon onu port 4 ctc rate-limit 55000 ingress

 

    то суммарно все четыре порта ОНУ не смогут прокачать больше 55Мбит/с

 

P.S. Возможно попутал ingress/egress ... Но не суть важно.

Ссылка на сообщение
Поделиться на других сайтах

Новая прошивка для FORA NA-1001B, решающая проблему с Option 82, выложена на дроп https://www.dropbox.com/sh/r35rr8qrh7dxygv/AABZRUkALVmufqJEHD6BmRmya?dl=0.

Напомню, UImage шьём через веб морду, архив jffs2_fs.tar.gz - через CLI OLT-а (как говорится, кому как больше нравится).

Спасибо, будем пробовать.

Ссылка на сообщение
Поделиться на других сайтах

 

Rate-limit - это полисинг, т.е. жёсткое обрезание трафика, ведущее к потерям пакетов. Шейпинг - обрезание трафика более мягкое (с использованием размера TCP окна... если я не прав, поправьте).

Нет.

Полисинг тупо дропает пакеты, которые не влазят в rate-limit.

Шейпер же пытается такие пакеты поставить в очередь и затормозить, т.е. таким образом заставить отправителя медленнее отправлять данные. Ну и уже "непослушных" дропает.

 

Вообще - да, шейпер более толерантен к TCP, но глубже ethernet кадров обычно не лезет и сам по себе о TCP (как и о всём остальном) знать не знает.

 

Можно сказать проще - полисер, это шейпер с буфером нулевого размера. Больше никакой разницы нет.

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

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

    • Від Inna13
      Наша компанія має стаж роботи понад 15 років. У нас є дві форми оплати з ПДВ та ФОП, гарантія на товар. Найкращі ціни. В наявності і під замовлення. Picotel, Ubiquiti, BDCOM, C-DATA, Picotel, RCI та інші
    • Від Костопашка
      Куплю этажные боксы (аналогичные Депс и Ромсат не предлагать) 

    • Від Maks1m
      Для будівництва мережі в Києві та області потрібні бригади кабельщиків та зварювальників. 
      За додатковою інформацією прохання звертатися в особисті. 
    • Від Inna13
      Продаж великого асортименту телекомунікаційного обладнання. Компанія працює більше 15 років. Опт і роздріб. Ціни з ПДВ і без. Дистрибьютори ТМ "Ютекс". Оптичне обладнання PON (GPON, GEPON, XPON), кабельна продукція, комутатори, маршрутизатори, інструменти для пон мереж, шафи і стійки, власне виробництво PON боксів.
    • Від andr1y
      Запрошуємо на постійну роботу монтажників кабельних мереж (м.Львів)
       
      Вимоги:
      відповідальне ставлення до роботи, якісне і оперативне виконання поставлених завдань, дисциплінованість; ініціативність, та швидкість у навчанні; охайність та орієнтованість на результат; перевагою буде наявність власного авто Умови роботи:
      повна зайнятість стабільна, своєчасна заробітна плата додаткові бонуси/премії за виконану роботу оплата амортизації та палива при використанні власного автомобіля в робочих цілях ми пропонує стабільну роботу та професійний розвиток.  
      Детальніша інформація по тел.: 067-433-73-19 Ярослав

×
×
  • Створити нове...