Перейти до

sfc

Сitizens
  • Всього повідомлень

    797
  • Приєднався

  • Останній візит

Все, що було написано sfc

  1. sfc

    UA.PON v4.0

    Имелось ввиду полукольцом - это у меня на плоншете пальцы в кнопки не попадали. повеселили
  2. sfc

    Нужна помощь в настройке Rocket M2

    для началу нужно построить более достоверный профиль. тогда будет точно понятно "дрянь" или есть варианты
  3. sfc

    Нужна помощь в настройке Rocket M2

    Грей, "картина" не тянет даже на "не фонтан"! линк-тест сам по себе не очень корректный сервис. 20 км - приличная дистанция, должна учитываться кривизна земли. здесь этого нет. нет данных, что находится на препятствующей возвышенности. если там еще и лес, то вообще засада. несколько исправить ситуацию поможет переход на 5 ггц и увеличение высоты подвеса на стороне точки 1. чтобы вы понимали, Земеля вам пытался указать диаметр эллипсоида 1-й зоны френеля в центре дистанции. видимо, указал "на глазок". на самом деле, максимальный диаметр на дистанции 20 км при частоте 2,4 ггц около 25 м. могу завтра (ближе к вечеру) сделать более точный профиль. координаты отправляйте в лс. по вопросам: 1. витая пара обязательно экранированная уличная. разъемы - экранированные. заземлять в одной точке, внизу. не зануляйте, ни в коем случае! 2. ставить грозозащиту желательно со стороны соответствующего порта коммутатора/маршрутизатора. именно этот порт и будет защищать грозозащита. 3. для более надежной и зазищенной от каверзных абонентов работы схемы, вам нужно как минимум 2 vlan и соответсвующие им подсети. в первом - ваше оборудование, во втором - клиентское оборудование и клиентский трафик. надо понимать, что речь идеть о построении полностью управляемой сети. 4. по моему мнению, в вашем случае будет правильнее на клиентской стороне включить маршрутизацию и dhcp на стороне lan. на стороне wlan прописать фиксированный ip из подсети вашего оборудования. администрирование клиентской точкой оставить за провайдером (удаленно). 5. необходимость в тунеллировании, наличии выделенных vlan и т.п. напрямую зависит от того, желаете ли вы изолировать своих абонентов друг от друга, делить их на группы и т.д. п.с. Укр-пацан в этом сам "пионер"... вы, я так понимаю, тоже... что в вас радует, так это не поиск халявы, а поиск оплачиваемого (наемного) работника. а разрешительные документы уже есть?
  4. sfc

    UA.PON v4.0

    предлагаете похоливарить прав ли был Адам Смит?
  5. sfc

    UA.PON v4.0

    так его и нет по "дефолту". рынок молчит, спроса нет ( и правильно, еще нет такой надобности), нет и предложения. будет спрос, китайцы засуетятся и в этом направлении. п.с. я вообще о нем ("dwdm-pon") ничего не читал. это были мои личные умозаключения. я бы не говорил, что его нет. это никто не использует за ненадобностью. но, оборудование на основе которого все это можно построить существует. только это уже не развитие существующего pon, а его крупномасштабный апгрейд. по сути, от существующей сети остается только волокно. все остальное (olt, делители/ответвители, ont) нужно будет менять.
  6. sfc

    UA.PON v4.0

    благо это или нет - покажет время. не так ли? извините, мне просто показалось, что вы пытаетесь "опустить руки". не нужно этого делать. не придете в чс вы, придут другие - свято место пустым не останется. так лучше пусть заходит оператор с опытом, не единажды набивший себе шишки, чем залетный толстосум только потому, что ему вкрай этого чешется. рвения некоторых таких "пионеров" мы видим по вайфаю... еще раз, извините, что влез. все у вас обязательно получится!
  7. sfc

    UA.PON v4.0

    мое мнение только одно как более-менее рационально наростить уже существующие сети - переход на cwdm/dwdm в последней миле. я его только описал выше в сообщении к Гайджину.
  8. sfc

    UA.PON v4.0

    зря вы так отчаяно делаете выводы. вы, ваши коллеги (другие операторы/провайдеры), совместно с Владиславом делаете неоценимую работу по развитию этой технологии!!! не было бы вас - заказчиков оборудования, не делали бы его китайцы. именно вы постепенно и планомерно задаете "тон" развития и совершенствования технологии. да, возможно лет через 5...10...15 в вашей (многих операторов, кто сейчас развивает свои сети на основе пон) практике наступит весьма не легкое время. вы все равно добьетесь от китайцев (может, корейцев или еще кого, не важно) появления инновационных технологий для пон с приемлемой ценой. и придет на рынок какой-нибудь "вася пупкин", с мешком бабла, закупит новейшее оборудование, построит свою сеть и будет всем вашим абонентам рассказывать, что у Гайджина все говно, а у него круто. это, конечно, будет обидно всем вам. но такова жизнь - все течет, все меняется. мы с этим уже столкнулись, что называется "лицом к лицу". именно этого и пытается избежать Зуарасиз. даст бог, ему это удастся! хотя вряд ли ему это будет легко осуществить, не зная какой же именно будет новая технология. в принципе, от этого (тдма) можно избавится прямо сейчас, реализовав пассивную сеть доступа полностью на технологии dwdm. и скорость у абона "хоть жопой жри", и количество абонентов в одной трубке увеличивается с 64 до 80 (в перспективе до 160+), и не нужно никаких olt и onu с привязкой к одному производителю... и, тут снова ваш вопрос: "но какой ценой???" п.с. извините, если чем задел. ничем не хотел обидеть...
  9. sfc

    UA.PON v4.0

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

    xPON. Вопросы топологии.

    если кратенько, то что и все - черпаю информацию. а что до моих сообщений - то в обсуждениях рождается истина. и какая польза вам от меня требуется?
  11. sfc

    UA.PON v4.0

    Вы чего прикалываетесь? - не уж то не поняли сути вопроса, что так лихо в сторону съезжаете? Вы сделали вброс о том, что амеры подсели на GPON, а мы тут типа лохи на низкокачественную "дурь" в виде GEPONа приседаем. Вот я Вам и задал вопрос - Вы то сами способны определить качество той или иной "дури" и и последствия применения ее из расчета "по две дороги на брата"? При этом сделать это "осмысленно и аргументированно". p.s. в такой терминологии понятней? + поставил за "терминологию" а по серьезному, вопрос к вам, как к человеку, практически реализующему пон-технологию в своей сети. ваше личное мнение (пусть даже оно и будет субъективным - т.е. "на ваш личный вкус"), какой из стандартов все же более прогрессивен?
  12. sfc

    xPON. Вопросы топологии.

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

    xPON. Вопросы топологии.

    чисто спортивный интерес: можно объединить москвича с запорожецем?
  14. sfc

    UA.PON v4.0

    простите, а при чем энергетики до пона?
  15. sfc

    UA.PON v4.0

    ответ в вопросе
  16. sfc

    UA.PON v4.0

    В подобном виде не имеет смысла - нестабильность скорости если и как то взаимосвязана с разбалансом, то ни разу не результат разбаланса, а далеконе первая гармоника результата. Т.е. для контроля и числовой оценки событий нужны гораздо более точные показатели чем скорость на трех не родных ОНУшках. конечно, желательно "собрать" полновесное дерево и делать анализ не только скорости, а всех возможных параметров.
  17. sfc

    UA.PON v4.0

    я видел, что вы интересовались динамическим диапазоном. просто не стал на этом акцентироваться. я пока не претендую на верность выводов. заметьте, долго не писал вообще своего предположения. хотел сначала сам убедиться в его справедливости.
  18. sfc

    UA.PON v4.0

    я обратил внимание на ваш первый эксперимент. там вы указывали на наличие нестабильности в скорости. у меня есть ничем не подтвержденное предположение, что скачки скорости могут являться результатом расбалансированной по уровням схемы подключения onu. для того, что бы понять так это или нет (правильны ли мои предположения или нет) яи прошу вас провести второй эксперимент. схему составьте сами, как вам это будет удобно. главное, что в ней должно присутствовать: 1. тот же olt и те же onu, что участвовали в первом эксперименте; 2. потери в пассивной части экспериментальной схемы между olt и каждым из onu должны быть максимально идентичными; 3. очень желательно сгенерировать такой же трафик, как и в первом эксперименте. какой хотелось бы получить ответ в результате: остались ли "скачки" скорости как в первом эксперименте или что-то изменилось и в какую сторону. п.с. для меня этот результат лишь удовлетворение любопытства. но, как мне кажется он будет гораздо важен для других форумчан, которые занимаются проектированием, строительством и эксплуатацией пон-сетей. даже, если мои предположения пусты - это лишний повод для них не сильно беспокоиться о расбалансировке их сетей. если ваш опыт даст положительный результат, то для них это будет подспорьем на будущее при расширении их сети. спасибо.
  19. sfc

    UA.PON v4.0

    От ONU к OLT не должно приходить мощнее чем -10dBm, в любом случае надо читать спецификацию к оборудованию. я не оспариваю спецификацию. я свою гипотезу основываю на принципах работы любого приемника. предположение изложил выше
  20. sfc

    UA.PON v4.0

    опишу суть моего предположения. любой приемник обладает динамическим диапазоном - разницей между максимальным уровнем на входе и его чувствительностью. при этом уровень сигнала, подаваемого на вход детектора (демодулятора) должен находится в достаточно узких пределах. приведением уровня входного сигнала (в пределах динамического диапазона) к необходимому уровню на входе детектора выполняется посредством ару. чем больше динамический диапазон, тем шире диапазон ару. но схема ару достаточно инерционна относительно частоты сигнала (а соответственно, и скорости потока). отсюда что имеем: 1. для приемника onu уровень входного сигнала всегда относительно одинаков. его схема ару находится приблизительно в одной точке. на демодулятор подается стабильный во времени сигнал. проблем в пределах динамического диапазона никаких. 2. для приемника olt при расбалансированной схеме уровень входного сигнала от абонента к абоненту постоянно меняется. соответственно, его схема ару находится постоянно в интенсивной работе. на эту "работу" необходимо время. и этого времени нужно тем больше, чем более расбалансирована схема волокна. отсюда могут возникать "провалы" в скорости восходящего потока на промежутки времени, необходимые для срабатывания ару. готов выслушать критику своего предположения.
  21. sfc

    UA.PON v4.0

    А вот и зря. В части ОНУ как раз все проще, а вот в отношении ОЛТа я поддерживают ZuarasiZ-а.Вот еще чудный документик - http://grouper.ieee.org/groups/802/3/efm/public/nov01/gummalla_1_1101.pdf во-во-во! чудненький документик! не читал, достаточно было взглянуть на функциональную схемку! это только подтверждает мою теорию.
  22. sfc

    UA.PON v4.0

    в этом никто и не сомневается. однако, имеется одно "но", которое получил человек на экспериментальной схеме. он сам отметил это "но" - нестабильность скорости п.с. вот, если при втором тесте эта нестабильность останется, тогда можно смело плевать на расбалансировку. а причину искать в другом...
  23. sfc

    UA.PON v4.0

    в части onu я с вами согласен. а в части olt у меня несколько иное предположение. очень хочется получить бы от Hapelа второй эксперимент...
  24. sfc

    UA.PON v4.0

    у меня есть чисто теоретическое предположение, что "гасить" все же имеет смысл. именно, для подтверждения или опровержения своего предположения я и просил Hapelа сделать повторный опыт уже на сбалансированной схеме. С вопросом Toonа в части "как много абонентов включено на реально работающей расбалансированной сети?" я согласен. этот вопрос находится во взаимосвязи с моим предположением.
  25. sfc

    Настройка точки доступа Rocket M2 Dish

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