В процессе миграции с NTFS на ext3 неаккуратно обошелся я с одним разделом. Точнее, в KDE Partition Manager'е решил испытать опцию "Move". Получил сообщение об ошибке... и 2 пустых раздела вместо пустого пространства и исходного раздела.
Попробовал разобраться с testdisk: инструмент интересный, нашел разные мертвые файловые системы, но то ли не сумел найти следы моего раздела, то ли я это не увидел...
Попробовал photorec из того же пакета: запустил на пустом пространстве, много файлов восстановилось, но не все корректно, плюс исходные названия потерялись.
В планах было еще воспользоваться gpart - старый инструмент, но отзывы хорошие.
Потратив полдня решил идти по пути наименьшего сопротивления: загрузился в винду, запустил Acronis Disk Director Suite и на пустом пространстве (где были данные) включил Recovery в быстром режиме. Он просканировал диск, нашел видимо бэкапные записи 2 файловых систем - успешно удаленной ранее NTFS и нечаянно поломаной ext3.
Применил изменения и вуаля! Раздел и данные снова на месте.
понедельник, 14 июня 2010 г.
воскресенье, 23 мая 2010 г.
"Селективная" виртуализация
Хочется сделать такую схему виртуализации на домашнем компьютере (он же медиа-центр и сервер):
1. Гипервизор
2. Гостевая (guest OS) Windows
3. Гостевая Linux
Здесь всё как обычно.
Что необычного?
Хочется запускать windows в виртуальной мешине и в то же время иметь близкую к нативной 2D/3D-производительность и вывод на физический дисплей.
В винде запускаются игры, поэтому нужно выделить или пробросить в гостевую win
- видеокарту - плюс с нее уходит и звук по HDMI;
- USB-порт - через него работает приемник беспроводных клавы и мыши.
Я пока вижу 2 варианта:
1. Искать информацию, читать интернет - основной вариант
2. Проверить производительность VirtualBox, благо на ноутбуке он есть. Запустить не самую новую игру типа GTA San Andreas и посмотреть.
1. Гипервизор
2. Гостевая (guest OS) Windows
3. Гостевая Linux
Здесь всё как обычно.
Что необычного?
Хочется запускать windows в виртуальной мешине и в то же время иметь близкую к нативной 2D/3D-производительность и вывод на физический дисплей.
В винде запускаются игры, поэтому нужно выделить или пробросить в гостевую win
- видеокарту - плюс с нее уходит и звук по HDMI;
- USB-порт - через него работает приемник беспроводных клавы и мыши.
Я пока вижу 2 варианта:
1. Искать информацию, читать интернет - основной вариант
2. Проверить производительность VirtualBox, благо на ноутбуке он есть. Запустить не самую новую игру типа GTA San Andreas и посмотреть.
воскресенье, 11 апреля 2010 г.
Тестируем пропускную способность WiFi с iPerf
Intro
Есть беспроводная сеть. Но скорость передачи файлов бывает падает до 700 кБ/с и ниже. Так что захотелось выяснить, в чем дело: где узкое место и кого давит жаба.
Вероятные источники проблемы:
- Интерференция
- Другой трафик
- Ноутбук или точка ASUS WL-500W: неудачаная реализация/драйверы/система
Для проверки этих гипотезы подойдет iPerf - открытый и бесплатный инструмент для тестирования пропускной способности сети. Работает под Linux и Windows (здесь), интерфейс - командная строка (отмечу, что есть еще jPerf - переписан на Java и с графическим интерфейсом).
В Debian устанавливается через:
apt-get install iperf
Запуск
Одна сторона - сервер: iperf -s
Другая сторона - клиент: iperf -c Server_IP
При этом iperf замеряет пропускную способность по TCP от клиента к серверу. Для полудуплексной беспроводной сети это и нужно, трафик идет от беспроводного клиента (ноутбук) через точку доступа к компьютеру в обычной сети.
В других случаях может быть полезной опция -d (Do a bidirectional test simultaneously).
В ходе тестов удалось посмотреть как ведет себя сеть и убедиться, что действительно в разное время пропускная способность разная.
Нормальное поведение
sk@hal:~$ iperf -i 5 -t 20 -c 192.168.0.65
------------------------------------------------------------
Client connecting to 192.168.0.65, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.0.63 port 33344 connected with 192.168.0.65 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 5.0 sec 13.2 MBytes 22.1 Mbits/sec
[ 3] 5.0-10.0 sec 12.9 MBytes 21.7 Mbits/sec
[ 3] 10.0-15.0 sec 13.2 MBytes 22.1 Mbits/sec
[ 3] 15.0-20.0 sec 13.3 MBytes 22.3 Mbits/sec
[ 3] 0.0-20.0 sec 52.5 MBytes 22.0 Mbits/sec
Как видно, при теоретическом пороге для полудуплексного 802.11g в 27 Мбит/c мы получаем приемлемое значение около 22-23 Мбит/c. Передача файла по SMB с линукс-станции на виндовую шару в такое время выдает 2 Мбайт/c = 16 Мбит/с, что кажется приемлемым, учитывая болтливость протокола SMB.
Аномальное поведение
sk@hal:~$ iperf -i 5 -t 20 -c 192.168.0.65
------------------------------------------------------------
Client connecting to 192.168.0.65, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.0.63 port 37460 connected with 192.168.0.65 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 5.0 sec 12.7 MBytes 21.3 Mbits/sec
[ 3] 5.0-10.0 sec 10.1 MBytes 16.9 Mbits/sec
[ 3] 10.0-15.0 sec 6.71 MBytes 11.3 Mbits/sec
[ 3] 15.0-20.0 sec 2.33 MBytes 3.91 Mbits/sec
[ 3] 0.0-20.5 sec 31.8 MBytes 13.0 Mbits/sec
Что-то происходит и скорость начинает падать. Вот продолжение:
[ 3] 0.0- 5.0 sec 4.71 MBytes 7.90 Mbits/sec
[ 3] 5.0-10.0 sec 5.09 MBytes 8.53 Mbits/sec
[ 3] 10.0-15.0 sec 3.92 MBytes 6.58 Mbits/sec
[ 3] 15.0-20.0 sec 6.41 MBytes 10.7 Mbits/sec
Отключение домашней сети (плоская сеть с сотней компьютеров) ситуацию не меняет.
Остаются варианты:
а) интерференция - микроволновки и т.п.
б) левый трафик в беспроводной сети: нужно при случае перевести карточку в monitor mode и посмотреть, что там бегает.
Диагностика в режиме UDP
А пока я успел перевести iperf в режим работы через UDP и пронаблюдал следующую интересную картину.
sk@hal:~$ iperf -i 5 -t 300 -c 192.168.0.65 -u -b 25m
------------------------------------------------------------
Client connecting to 192.168.0.65, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 110 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.0.63 port 35797 connected with 192.168.0.65 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 5.0 sec 9.81 MBytes 16.5 Mbits/sec
[ 3] 5.0-10.0 sec 14.7 MBytes 24.7 Mbits/sec
[ 3] 10.0-15.0 sec 6.57 MBytes 11.0 Mbits/sec
[ 3] 15.0-20.0 sec 14.9 MBytes 25.0 Mbits/sec
[ 3] 20.0-25.0 sec 14.9 MBytes 25.0 Mbits/sec
Т.е. удалось запечатлеть момент когда закончилась "яма" и скорость снова вышла на нормальный уровень.
На самом деле тестирование по UDP в случае беспроводной сети позволяет заглянуть еще дальше и точнее понять происходящее. Вот выходные данные на стороне сервера:
H:\soft\Network\iPerf, jPerf>iperf -s -i 5 -u
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size: 8.00 KByte (default)
------------------------------------------------------------
[1928] local 192.168.0.65 port 5001 connected with 192.168.0.63 port 35797
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[1928] 0.0- 5.0 sec 9.84 MBytes 16.5 Mbits/sec 0.602 ms 0/ 7022 (0%)
[1928] 5.0-10.0 sec 14.7 MBytes 24.7 Mbits/sec 0.600 ms 0/10521 (0%)
[1928] 10.0-15.0 sec 6.57 MBytes 11.0 Mbits/sec 0.591 ms 0/ 4684 (0%)
[1928] 15.0-20.0 sec 14.9 MBytes 25.0 Mbits/sec 0.590 ms 0/10609 (0%)
[1928] 20.0-25.0 sec 14.9 MBytes 25.0 Mbits/sec 0.586 ms 0/10638 (0%)
Видно что потерь пакетов нет. UDP, как известно, протокол без потверждения доставки; в отличии от TCP он не может адаптироваться к заторам в сети; UDP-клиент (в нашем случае iperf) отсылает трафик с возможной для него скоростью (для iperf выставлено 25 Мбит/c).
Но мы видим, что в "яме" скорость отправки составляла 16.5 Мбит/с и даже 11.0 Мбит/с. Вместе с тем, нет сброшенных пакетов и ошибок, в сети ничего не потерялось. Значит, что-то не давало клиенту возможности отправлять трафик в сеть с большей скоростью. Что это?
Это - механизм контроля доступа к беспроводной среде - CSMA/CA (Carrier sense multiple access with collision avoidance). Он мониторит среду и обнаруживает, что какая-то станция уже передает трафик, и не позволяет отправить фрейм в этот момент.
Т.е. тест показывает, что в беспроводной сети присутствует некий "левый" (с моей точки зрения) трафик; остается его идентифицировать и принять меры по лечению...
Что касается iPerf, он снова хорошо показал себя: легкий, удобный и удивительно полезный инструмент.
Подписаться на:
Сообщения (Atom)