неправильно идущее время
Все неправы 
А что за плата такая, не та самая платформа случайно ?
Насколько плохо там идут часы?
А что за плата такая, не та самая платформа случайно ?
Насколько плохо там идут часы?
Я хз, что за плата. На virgin сгорела (см. v.gz.ru вставили новую. Вставляли без меня. Часы там уходят примерно на час в сутки, и не плавно. То есть ускорить время не катит.
Имхо, пока софт будет писаться человеком - от этого никуда не деться,
вернее даже по другому:
пока софт не будет автоматически доводиться под конкретное окружение - таких проблем не избежать.
вернее даже по другому:
пока софт не будет автоматически доводиться под конкретное окружение - таких проблем не избежать.
> Вставляли без меня.
Этточно, чуть не проследишь - обязательно что-нибудь не так сделают
Этточно, чуть не проследишь - обязательно что-нибудь не так сделают
Авторы неправы.
Если система существенно опирается на реальность времени,
она должна быть написана соответствующим образом.
Да, можно улучшать временные свойства ПО за счёт использования
более быстрого и т. п. аппаратного обеспечения,
но от ошибок это не особо предохраняет.
---
...Я работаю антинаучным аферистом...
Если система существенно опирается на реальность времени,
она должна быть написана соответствующим образом.
Да, можно улучшать временные свойства ПО за счёт использования
более быстрого и т. п. аппаратного обеспечения,
но от ошибок это не особо предохраняет.
---
...Я работаю антинаучным аферистом...
> опирается на реальность времени
В данном случае, система скорее опирается на непрерывность и монотонность времени
В данном случае, система скорее опирается на непрерывность и монотонность времени
А просто поставить синхронизацию с тем же NTP скажем раз в минуту не пробовали ? 
Авторы как раз правы.
Zebra написана очень аккуратно.
А вот то, что она работает на таком оборудовании это как-раз неправильно.
Zebra написана очень аккуратно.
А вот то, что она работает на таком оборудовании это как-раз неправильно.
СРВ должна сама проверять ограничения.
Вместе с отказами оборудования.
---
...Я работаю антинаучным аферистом...
Вместе с отказами оборудования.
---
...Я работаю антинаучным аферистом...
> то zebra серьезно глючит
а как именно глючит кстати?
а как именно глючит кстати?
Не понял глубины твоей мысли.
Что есть СРВ ?
Также вопрос номер 2.
В курсе ли ты функциональности Zebra или же ты идешь из теоритических предпосылок ?
Что есть СРВ ?
Также вопрос номер 2.
В курсе ли ты функциональности Zebra или же ты идешь из теоритических предпосылок ?
> СРВ должна сама проверять ограничения.
> Вместе с отказами оборудования.
То, что на данном процессоре 2+2 всегда получается 4 - тоже надо проверять?
> Вместе с отказами оборудования.
То, что на данном процессоре 2+2 всегда получается 4 - тоже надо проверять?
есть сервисы, которые плавно подгоняют время при синхронизации (по крайней мере в винде)
Система реального времени.
То, что "Зебра" зависит от времени очевидно из постановки вопроса.
---
...Я работаю антинаучным аферистом...
То, что "Зебра" зависит от времени очевидно из постановки вопроса.
---
...Я работаю антинаучным аферистом...
Если случается непредвиденная ошибка,
система должна возможно более правильно остановиться.
---
...Я работаю антинаучным аферистом...
система должна возможно более правильно остановиться.
---
...Я работаю антинаучным аферистом...
Маленький ликбез.
Zebra не "система реального времени".
Zebra это эмулятор Cisco. Роутинговый софт.
Да, некоторые функции действительно критичны к скачкам времени, но если б этих скачков не было, все б работало нормально.
Так что, твои выкладки, здесь не к месту.
Zebra не "система реального времени".
Zebra это эмулятор Cisco. Роутинговый софт.
Да, некоторые функции действительно критичны к скачкам времени, но если б этих скачков не было, все б работало нормально.
Так что, твои выкладки, здесь не к месту.
> Если случается непредвиденная ошибка,
> система должна возможно более правильно остановиться.
Совсем не вижу разницу между глюками и аварийным остановом.
Для больших систем, в реальной жизни, первое даже лучше, чем второе.
> система должна возможно более правильно остановиться.
Совсем не вижу разницу между глюками и аварийным остановом.
Для больших систем, в реальной жизни, первое даже лучше, чем второе.
>Для больших систем, в реальной жизни, первое даже лучше, чем второе.
Золотые слова.
Золотые слова.
если говорить о роутерах, то остановка роутера при сбое предпочтительнее, чем странные глюки
ещё предпочтительнее автоматическая перезагрузка (с дампом отладочной информации но только при условии, что это не слишком часто
ещё предпочтительнее автоматическая перезагрузка (с дампом отладочной информации но только при условии, что это не слишком часто
> если говорить о роутерах, то остановка роутера при сбое предпочтительнее, чем странные глюки
т.е. отсутствие инета у всех - это лучше, чем глюки у части народа?
т.е. отсутствие инета у всех - это лучше, чем глюки у части народа?
> ещё предпочтительнее автоматическая перезагрузка (с дампом отладочной информации но только при условии, что это не слишком часто
Настрой watch dog, чтобы он при появление глюков ребутал router не слишко часто.
Настрой watch dog, чтобы он при появление глюков ребутал router не слишко часто.
Проще очистить таблицу роутинга и заполнить ее заново, чем рубутать всю машину.
Да и предпочтительнее.
Да и предпочтительнее.
> т.е. отсутствие инета у всех - это лучше, чем глюки у части народа?
"В реальной жизни, в больших системах" выключение одного роутера не приводит к "отсутствию инета у всех".
> Настрой watch dog, чтобы он при появление глюков ребутал router не слишко часто.
Для этого ему нужно уметь определять, что глюки появляются, а тогда это уже
будут не глюки, а аварийный останов.
"В реальной жизни, в больших системах" выключение одного роутера не приводит к "отсутствию инета у всех".
> Настрой watch dog, чтобы он при появление глюков ребутал router не слишко часто.
Для этого ему нужно уметь определять, что глюки появляются, а тогда это уже
будут не глюки, а аварийный останов.
> Для этого ему нужно уметь определять, что глюки появляются, а тогда это уже
> будут не глюки, а аварийный останов.
Там может все-таки лучше копромиссное решение?
софт при возникновении ошибки обновляет log-файл, но продолжает работать, возможно с глюками.
Соответственно watch dog проверяет log-файл.
> будут не глюки, а аварийный останов.
Там может все-таки лучше копромиссное решение?
софт при возникновении ошибки обновляет log-файл, но продолжает работать, возможно с глюками.
Соответственно watch dog проверяет log-файл.
> софт при возникновении ошибки обновляет log-файл
так проблема в том, что ошибка не обнаруживалась, или не считалась ошибкой
поэтому были глюки, заметные человеку, но не заметные программе
собственно, в этом авторы и неправы - не обработали все случаи
(В отличии от 2+2 != 4, скачки времени бывают не только при аппаратных сбоях)
так проблема в том, что ошибка не обнаруживалась, или не считалась ошибкой
поэтому были глюки, заметные человеку, но не заметные программе
собственно, в этом авторы и неправы - не обработали все случаи
(В отличии от 2+2 != 4, скачки времени бывают не только при аппаратных сбоях)
А просто поставить синхронизацию с тем же NTP скажем раз в минуту не пробовали ?Читаем исходный пост внимательнее
Во, придумал, кто ещё неправ.
Вместо gettimeodfay и производных для таких целей (таймауты в сетевых протоколах, так?) лучше всего было бы использовать
не часы реального времени, а специальный счётчик, для которого гарантируется монотонность,
но не гарантируется аккуратность. Счётчик тиков таймера (при достаточном разрешении оного) - идеальный вариант.
AFAIK стандартное API такого не предоставляет, или я не знаю просто?
Вместо gettimeodfay и производных для таких целей (таймауты в сетевых протоколах, так?) лучше всего было бы использовать
не часы реального времени, а специальный счётчик, для которого гарантируется монотонность,
но не гарантируется аккуратность. Счётчик тиков таймера (при достаточном разрешении оного) - идеальный вариант.
AFAIK стандартное API такого не предоставляет, или я не знаю просто?
> > то zebra серьезно глючит
> а как именно глючит кстати?
bgpd рвет сессию, если скачок времени вперед выше hold time для данного neighbor
ospfd заходит в бесконечный цикл (зависает) если скачок времени вперед выше LSA refresh interval.
у ripd пока проблем не замечено
ospf6d не тестировался
zebra проблем не замечено, и по идее не должна она временем пользоваться
> а как именно глючит кстати?
bgpd рвет сессию, если скачок времени вперед выше hold time для данного neighbor
ospfd заходит в бесконечный цикл (зависает) если скачок времени вперед выше LSA refresh interval.
у ripd пока проблем не замечено
ospf6d не тестировался
zebra проблем не замечено, и по идее не должна она временем пользоваться
Маленький ликбез.Согни пальцы назад. Это ни какой не эмулятор, а реализация набора протоколов.
Zebra не "система реального времени".
Zebra это эмулятор Cisco. Роутинговый софт.
Да, некоторые функции действительно критичны к скачкам времени, но если б этих скачков не было, все б работало нормально.А если системный администратор поменял время с помощью date(1)?
> bgpd рвет сессию, если скачок времени вперед выше hold time для данного neighbor
вполне логично, ему ничего не остаётся делать, тут авторы правы
хотя вот тут как раз бы и пригодились бы тики таймера вместо реального времени
> ospfd заходит в бесконечный цикл (зависает) если скачок времени вперед выше LSA refresh interval
а вот тут - не правы, зависать - не дело, независимо от
вполне логично, ему ничего не остаётся делать, тут авторы правы
хотя вот тут как раз бы и пригодились бы тики таймера вместо реального времени
> ospfd заходит в бесконечный цикл (зависает) если скачок времени вперед выше LSA refresh interval
а вот тут - не правы, зависать - не дело, независимо от
Проще очистить таблицу роутинга и заполнить ее заново, чем рубутать всю машину.Нет, когда инвариант нарушен, то нужно падать в кору целиком (в нашем случае не обязательно роутеру, а всего лишь процессам зебры). Это общее правило программирования. Если так не делать, то никогда всех багов не выловишь.
Да и предпочтительнее.
> Нет, когда инвариант нарушен, то нужно падать в кору целиком (в нашем случае не обязательно роутеру, а всего лишь процессам зебры).
Замечу, что взрыв французской ракеты Ареан 5, а также полный отказ марсоходов вызван как раз этим правилом.
Замечу, что взрыв французской ракеты Ареан 5, а также полный отказ марсоходов вызван как раз этим правилом.
Вместо gettimeodfay и производных для таких целей (таймауты в сетевых протоколах, так?) лучше всего было бы использоватьЯ об этом вчера думал. Хотел еще здесь спросить, существует ли такое в каких нибудь ОС?
не часы реального времени, а специальный счётчик, для которого гарантируется монотонность,
но не гарантируется аккуратность. Счётчик тиков таймера (при достаточном разрешении оного) - идеальный вариант.
AFAIK стандартное API такого не предоставляет, или я не знаю просто?
Но если существует, то будет ли правильным использование этого API? Ведь по спецификации протокола мы должны работать в секундах, а не единицах времени неопределенного размера. Ведь в сообщениях этих протоколов часто фигурируют секунды. Что бы будем передавать соседним роутерам?
> > Нет, когда инвариант нарушен, то нужно падать в кору целиком (в нашем случае не обязательно роутеру, а всего лишь процессам зебры).
> Замечу, что взрыв французской ракеты Ареан 5, а также полный отказ марсоходов вызван как раз этим правилом.
Возможно продолжение работы с нарушенным вариантом привело бы к более тяжелым последствиям.
Кстати какого фига взрыв произошел? Взрыватель должен стопориться при нарушении чего либо, а не приходить в действие.
> Замечу, что взрыв французской ракеты Ареан 5, а также полный отказ марсоходов вызван как раз этим правилом.
Возможно продолжение работы с нарушенным вариантом привело бы к более тяжелым последствиям.
Кстати какого фига взрыв произошел? Взрыватель должен стопориться при нарушении чего либо, а не приходить в действие.
> Хотел еще здесь спросить, существует ли такое в каких нибудь ОС?
Ну в общем да.
В линуксе можно /proc/uptime прочитать, но после 5минутного изучения исходников
у меня сомнения, что это то, что надо.
Монотонность там есть, но вот с непрерывностью непонятно, а свойство тоже полезное.
> Ведь по спецификации протокола мы должны работать в секундах, а не единицах времени неопределенного размера.
Ну это будут приблизительные секунды, точность зависит от точности таймера.
Если более точных часов нет, то ничего лучше не придумать.
Ну в общем да.
В линуксе можно /proc/uptime прочитать, но после 5минутного изучения исходников
у меня сомнения, что это то, что надо.
Монотонность там есть, но вот с непрерывностью непонятно, а свойство тоже полезное.
> Ведь по спецификации протокола мы должны работать в секундах, а не единицах времени неопределенного размера.
Ну это будут приблизительные секунды, точность зависит от точности таймера.
Если более точных часов нет, то ничего лучше не придумать.
Всё проще - в данном случае "вылавливать все баги" было уже поздно, поэтому правило стало неприменимым.
И ещё интересно, что делают poll и select при скачках времени, и что стандарты говорят по этому поводу.
> Это ни какой не эмулятор, а реализация набора протоколов.
Не занудствуй.
Кто хоть раз работал с Cisco для себя отличий практически не найдет.
Не занудствуй.
Кто хоть раз работал с Cisco для себя отличий практически не найдет.
> Я об этом вчера думал. Хотел еще здесь спросить, существует ли такое в каких нибудь ОС?
Под win2k есть QueryPerformanceCounter/QueryPerformanceFrequency
Под win2k есть QueryPerformanceCounter/QueryPerformanceFrequency
> Кстати какого фига взрыв произошел?
Небольшой сбой привел к аварийному останову всего ПО.
При отсутствии ПО - процесс быстро перешел в неуправляемое состояние.
> Взрыватель должен стопориться при нарушении чего либо
Процесс "стопорения" - это должно делать ПО или нет?
Если ПО, то как оно это сделает, если оно аварийно завершилось.
Небольшой сбой привел к аварийному останову всего ПО.
При отсутствии ПО - процесс быстро перешел в неуправляемое состояние.
> Взрыватель должен стопориться при нарушении чего либо
Процесс "стопорения" - это должно делать ПО или нет?
Если ПО, то как оно это сделает, если оно аварийно завершилось.
> > Это ни какой не эмулятор, а реализация набора протоколов.
> Не занудствуй.
> Кто хоть раз работал с Cisco для себя отличий практически не найдет.
[будем вежливыми, что бы не нервничал]
У zebra достаточно много отличий от роутеров Cisco.
> Не занудствуй.
> Кто хоть раз работал с Cisco для себя отличий практически не найдет.
[будем вежливыми, что бы не нервничал]
У zebra достаточно много отличий от роутеров Cisco.
Если учесть, что этот "небольшой сбой" был равнозначен 2x2<>4, то да --- небольшой.
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
> Процесс "стопорения" - это должно делать ПО или нет?
> Если ПО, то как оно это сделает, если оно аварийно завершилось.
Взрыв происходит когда завершается ПО? Тогда это design error. Взрыв должен инициироваться ПО.
Ведь винчестер не записывается нулями, когда ядро паникует.
> Если ПО, то как оно это сделает, если оно аварийно завершилось.
Взрыв происходит когда завершается ПО? Тогда это design error. Взрыв должен инициироваться ПО.
Ведь винчестер не записывается нулями, когда ядро паникует.
> Под win2k есть QueryPerformanceCounter/QueryPerformanceFrequency
Что делает?
Что делает?
Есть процессы - для нормальной работы которых, требуется работающее(хоть как-то) ПО.
Также есть процессы для корректного завершения которых необходимо работающее(хоть как-то) ПО
К таким процессам - относятся почти все процессы из реальной жизни:
работа светофоров,
движение автомашины,
полет самолета,
взлет ракеты,
работа ядерного реактора,
управление краном в ванной.
ps
ОС-ы, сетевое оборудование и т.д. - как раз лучше завершать корректно (когда завершатся все остальные процессы).
pps
Аварийно остановившийся роутер (или ОС) даже при управлении краном в ванном может привести к тяжелым последствиям.
Также есть процессы для корректного завершения которых необходимо работающее(хоть как-то) ПО
К таким процессам - относятся почти все процессы из реальной жизни:
работа светофоров,
движение автомашины,
полет самолета,
взлет ракеты,
работа ядерного реактора,
управление краном в ванной.
ps
ОС-ы, сетевое оборудование и т.д. - как раз лучше завершать корректно (когда завершатся все остальные процессы).
pps
Аварийно остановившийся роутер (или ОС) даже при управлении краном в ванном может привести к тяжелым последствиям.
> Что делает?
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/timers/timerreference/timerfunctions/queryperformancecounter.asp
http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/windowing/timers/timerreference/timerfunctions/queryperformancefrequency.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/timers/timerreference/timerfunctions/queryperformancecounter.asp
http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/windowing/timers/timerreference/timerfunctions/queryperformancefrequency.asp
> ОС-ы, сетевое оборудование и т.д. - как раз лучше завершать корректно (когда завершатся все остальные процессы).
Продолжение работы, когда нарушен инвариант файловой системы может привести к большим разрушениям, чем паника.
Продолжение работы, когда нарушен инвариант файловой системы может привести к большим разрушениям, чем паника.
Об отличиях и сходстве.
http://www.onlamp.com/lpt/a/2890
http://www.onlamp.com/lpt/a/2890
> Об отличиях и сходстве.
Спасибо за ссылку, но эту книгу я прочел полностью. Приведенный кусок скорее о преимуществах и недостатках, чем о отличиях и сходстве (за исключением заметки про zebra access-lists).
Спасибо за ссылку, но эту книгу я прочел полностью. Приведенный кусок скорее о преимуществах и недостатках, чем о отличиях и сходстве (за исключением заметки про zebra access-lists).
> Продолжение работы, когда нарушен инвариант файловой системы может привести к большим разрушениям
Такое когда еще будет, а паника - гарантированно приводит к плохим последствиям.
Такое когда еще будет, а паника - гарантированно приводит к плохим последствиям.
> > Продолжение работы, когда нарушен инвариант файловой системы может привести к большим разрушениям
> Такое когда еще будет, а паника - гарантированно приводит к плохим последствиям.
Это не врите. Паника для файловой системы эквивалентна сбою по питанию. Правильные файловые системы переживают такое. Продолжение работы с нарушенным инвариантом приведет к записи такой херни, что уже никакой scandisk не поможет.
> Такое когда еще будет, а паника - гарантированно приводит к плохим последствиям.
Это не врите. Паника для файловой системы эквивалентна сбою по питанию. Правильные файловые системы переживают такое. Продолжение работы с нарушенным инвариантом приведет к записи такой херни, что уже никакой scandisk не поможет.
> Правильные файловые системы переживают такое.
Неправильные, что характерно, обычно тоже переживают,
и в данном случае это важнее.
Неправильные, что характерно, обычно тоже переживают,
и в данном случае это важнее.
как, наверное, херово быть сисадмином.
Не, хреново ракеты на Марс запускать.
Ты наверное не весь тред прочитал.
Ты наверное не весь тред прочитал.
прочитал теперь весь. Сисадмином все равно быть хреново, имхо
блин, хотел обсудить хреновость жизни сисадминов (или плюсы а народ что-то не реагирует...
а народ что-то не реагирует...а в этом разделе нетипичные сисадмины
ура, кто-то отозвался.
А какие сисадмины типичные?
А какие сисадмины типичные?
Для файловой системы может быть и лучше, но дохнет вся остальная система - приводя к разрушительным последствиям.
ps
При нарушении каких инвариантов стоит впадать в панику? Всех?
ps
При нарушении каких инвариантов стоит впадать в панику? Всех?
> При нарушении каких инвариантов стоит впадать в панику? Всех?
Когда дальнейшая работа может привести к непоправимым последствиям.
Когда дальнейшая работа может привести к непоправимым последствиям.
> Когда дальнейшая работа может привести к непоправимым последствиям.
Но проблема-то при этом старая: сама подсистема (в данном случае файловая система) обычно не знает, что такое "непоправимые последствия". Для кого-то появление одного единственного bad-сектора - это уже повод для паники, а для кого-то и отключившийся винт - это норма.
Но проблема-то при этом старая: сама подсистема (в данном случае файловая система) обычно не знает, что такое "непоправимые последствия". Для кого-то появление одного единственного bad-сектора - это уже повод для паники, а для кого-то и отключившийся винт - это норма.
Оставить комментарий
sergey_m
Вопрос чисто философский. Вот есть софт, от которого требуется очень высокая стабильность. Выше чем у например web или почтового сервера. Конкретно речь идет о Zebra. Действительно вещь достаточно стабильная: если один раз сконфигурил и работает, то будет работать дальше. Однако оказывается, что когда время на машине идет неправильно, и ntpd его часто поправляет назад или вперед рывком в несколько десятков секунд, то zebra серьезно глючит. Критичные для себя глюки я исправил с помощью простых проверок того, что time не вернуло меньше чем в прошлый раз (не больше чем могло вернуть по логике программы).Собственно дилемма вот в чём. С одной стороны авторы не перестраховываются в проверках, когда пишут критически важный софт. С другой стороны, я не должен был ставить критически важный сервис на хуёвой материнской плате, где время скачет безумно. Кто прав?