» FreeArc (часть 4)

не могу поставить пароль на архив в FreeArc
метод как на картинке ниже не помогает, он распаковывает всё без запроса пароля....
http://www.pkgid.ru/imagesoft/freearc/freearc14.png

death7lord
gui там, прямо скажем, нелогичный. проще всего - после нажатия Add поставить галочку на Шифровании в первой закладке и затем нажать OK - он сам спросит пароль

да, это помогло, спасибо
но тогда возникает вопрос: а где в ISDone0.4.2.5 прописывать этот параметр??
if not ISArcExtract ( 0, OveralPct, 0, ExpandConstant('{src}\aa.bin'), ExpandConstant('{app}\'), false,CallBack, '', '', '') then break;

Mожет кто сталкивался с проблемой такой:
Качал торрент, вроде все нормально скачалось, перехешировал все совпадает на 100%, но при попытке открыть архив появляется
[more=Ошибка] [/more]

Попытался восстановить:
[more=Получаю]C:\Program Files (x86)\FreeArc\bin>arc r -tp- "W:\Half-Life 2 Anthology\games\Cinemat
ic Mod part1.arc"

FreeArc 0.67 (March 18 2011) recovering archive: W:\Half-Life 2 Anthology\games\
Cinematic Mod part1.arc

ERROR: W:\Half-Life 2 Anthology\games\Cinematic Mod part1.arc isn't archive or this archive is corrupt: block descriptor at pos 3059718000 is corrupted. Please recover it using 'r' command or use -tp- option to ignore Recovery Record[/more]
Длина файла в торренте "3059718154".

---

На всякий случай напишу железо и ОС, может из-за его:
Windows 7 SP1 x64. 6Gb ОЗУ, процессор q6600.


UPD.
Решил проблему следующим способом:
Отрезал в WinHex от конца файла все адреса до указанного в ошибке и докачал недостающие части.

death7lord
зашифрованные архивы может распаковать только arc.exe (да, это мой баг)

Народ, я тут новичок, кто-нибудь знает когда будет новая не-альфа версия FreeArc?

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

Методом тыка ранее выяснял, что вероятность успешной распаковки уменьшается не только в зависимости от сжимаемых файлов, но и от всяких объединений/перепаковок/добавлений в архив. В связи с этим у меня вопрос: есть ли какие-либо гарантии, что запакованные так-то и так-то файлы будут гарантированно распакованы?

Doctor_Freeman

Цитата:

Методом тыка ранее выяснял, что вероятность успешной распаковки уменьшается не только в зависимости от сжимаемых файлов, но и от всяких объединений/перепаковок/добавлений в архив. В связи с этим у меня вопрос: есть ли какие-либо гарантии, что запакованные так-то и так-то файлы будут гарантированно распакованы?

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

Иначе, если есть ошибка в FreeArc, то её не локализовать общими словами.

Doctor_Freeman

Версия 0,666 работает с ошибками на методах -мех5...-мех9
Версия 0,67а этих ошибок не имеет. Но ошибается при записи в формат .zip
Если в версию 0,67а записать файл 7z.dll от 7zip v9.20, то этих ошибок тоже не будет.
А больше я не знаю про ошибки.

а нельзя сделать чтобы архиватор при распаковке архива с методом 4x4 (например lzma:128mb:fast:96:mc20) учитывал параметр t (кол-во потоков), для данного файла ставил t2
а то получается смешная ситуация, запаковать смог, а распаковать нет ))
(использовался архиватор 0.666 build)
можно даже не указывать кол-во потоков, он все равно сможет запаковать, получается опция lc75p по-умолчанию работает, а опция ld75p - нет

кстати unarc успешно его распаковывает
(067 alpha 2011-03-18, 0.666 зависала [ошибки не было, просто нечего не делала])


оказывается что по умолчанию в normal preset match finder - ht4 ?
кстати а у него требование к памяти какое, в докуметации по lzma только hc4 есть, а ht4 - это же детище автора FA ))
и какой эффект дает hashsize (параметр h)?


и еще для tor в исходниках вроде написано что он принимает параметры многие, например p(parser ), однако я ввожу p1 или p3, но пишет ошибку, хотя кроме lazy greezy есть еще 3 парсера (3,4,5), но все равно пишет ошибку о неверном параметре

Здравствуйте! У меня такой вопрос: можно ли сделать опциональную распаковку arc-архивов в зависимости от выбранных пунктов? Я пробовал так:

[more]
#define ArcLocation "{app}\*.bin"

[Files]
Source: "data-1.bin"; DestDir: "{app}"; Flags: deleteafterinstall ;
Source: "data-2.bin"; DestDir: "{app}"; Flags: deleteafterinstall ; Check: 1;
Source: "data-3.bin"; DestDir: "{app}"; Flags: deleteafterinstall ; Check: 2;
[/more]

Но инсталятор просто выплёвывает все три архива, не распаковывая их. Если же не включать файлы в архив и писать #define ArcLocation "{src}\*.bin", то распаковываются сразу все архивы.

Можно ли решить мою проблему? Может быть тут такое уже обсуждалось, но я искал и не нашёл; так что извиняюсь за возможный повтор вопроса. Заранее спасибо.

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

какое преимущество дает использование future-lz
я понял что требование к памяти при распаковке ниже
но ведь память и так при распаковке очень малая (16мб)

kalpak

Цитата:

какое преимущество дает использование future-lz

скорость и щадащий режим для винта. А для памяти как раз наоборот

что значит щадящий режим ?
каким образом меньше операций i/o ?
он вроде побыстрее работает но вот насчет нагрузки на диск как то не заметил


странно, но среп стал неверно показывать память для упаковки
файл размером в 200мб
пишу srep -l256
(SuperREP 2.98 alpha)
он пишет

Цитата:

D:\free_arc067\bin>srep -l256 "d:\games\portal 2\portal2\portal2.zip"
56 mb, -m3 -l256 -c128 -a4

однако в диспетчере задач пишет 270мб под конец

если писать l128 то память пишется и тратиться корректно
если не писать то также непонятно куда утекает

с файлом около 1.5 гб получается так
с l128 память корректно тратиться
с любыми другими к середине уже больше 600мб память
даже с 1024 !!

для страховки везде прописал a1 все равно
(метод m3f везде, без f тоже проверял)

я разобрался
среп тот был скомпилирован мной вручную с помощью ms vs 2005
srep с ссылки автора работает корректно
кстати а чем srep32 отличается от srep ?
я peid проверил, там gcc компилятор, а в srep скорее всего ms vs 20xx
а разница между ними существенная ?i версия понятно побыстрее на intel-платформах

я все таки все их првоерил
такое же поведение у srep32/srep32i
у srep который в gcc построен все ок

кстати и теперь черtp arc\freearc не пашет, только вариант без -f пашет потому что я разделил srep

Цитата:

[External compressor:srep]
;options = l%d (minimal match length, default=512)
packcmd = srep {options} $$arcdatafile$$.tmp - <stdout>
unpackcmd = srep -d - - <stdin> <stdout>

[External compressor:srep_f]
;options = l%d (minimal match length, default=512)
packcmd = srep {options} -f - - <stdin> <stdout>
unpackcmd = srep -d - - <stdin> <stdout>

это у меня одного такие люки?

у меня не распаковываются файлы запакованные srep 2.98 alpha
если файл больше 2 гб то не распаковывается
если меньше то без проблем

во время упаковки никаких ошибок не пишет
а при распаковке

Цитата:

Ratio: 2,172,649,472 -> 2,137,387,555: 98.38%. Cpu 359.301 mb/sec, real 13.863 m
Ratio: 2,181,038,080 -> 2,145,776,191: 98.38%. Cpu 358.834 mb/sec, real 13.899 m
Ratio: 2,189,426,688 -> 2,154,164,827: 98.39%. Cpu 358.372 mb/sec, real 13.924 m
Ratio: 2,197,815,296 -> 2,162,553,463: 98.40%. Cpu 357.914 mb/sec, real 13.960 m
Ratio: 2,206,203,904 -> 2,170,942,099: 98.40%. Cpu 357.461 mb/sec, real 13.996 m
Ratio: 2,214,592,512 -> 2,179,330,735: 98.41%. Cpu 357.012 mb/sec, real 14.014 m
b/sec. Matches 5 4447 14188, I/Os 0, RAM 0/14, VM 0/0, R/W 0/0
ERROR! Decompression problem: broken compressed data

параметры упаковки -l128 -f -a1, файл размером 2.29 ГБ

winxp sp2, 2gb ram, core 2 duo 4300
на работе также только проц и СП другие
core-i5 650
win xp sp3


***
перепроверил, ошибка при распаковке бывает только при файле больше 2 гб если использовался -f, без -f все отлично распаковывается

все же. это нормально что при высоких lz min math память тратится даже больше чем при l32
я упаковываю файл 900 мб, у меня при параметрах -a4 под конец пишет уже более гб выделено, когда как требование к памяти в 10 раз меньше (95мб)
версия 2.0 так не ведет себя
вообще как то странно диспетчер показывает данные, я когад сворачиваю окно срепа то пишет что память 100 мб, тогда как на графике потребления памяти никаких изменений и в графе доступно нечего не меняется, а если сворачивать/разворачивать окно то память скачет то вниз то вверх

Posetitel33
надо задавать вопрос разработчику скрипта. или ты используешь скрипт из поставки freearc???

Добавлено:

Цитата:

какое преимущество дает использование  future-lz
я  понял что требование к памяти при распаковке ниже
но ведь память и так при распаковке очень малая (16мб)

почитай, вроде полтемы у нас srep'у посвещено. но если коротко - то обычный алгоритм берёт данные не из этих 16 мег, а считывает из предыдущей части файла. т.е. если LZ-код говорит ему "следующие 10 мб данных точно совпадают с тем что было 100 мб назад", то он просто читает их из уже распакованной части файла. учитывая, что кодируются все повторы от 512 байт - это огромная нагрузка на дисковый кеш, а если в него всё не влезет - то и сам диск

future-lz устроен наоборот - уже после распаковки первый раз этих 10 мб он говорит "они нам ещё понадобятся через 100 мб, давай сохраним их копию в памяти", и таким образом всё что будет повторено хранится в памяти и нагрузки на винт нет. если же даже озу для этих данных не хватит, то они собираются в куски по 8 мб, которые записываются/читаются целиком. по сравнению с первым вариантом, где куски могут быть по 512 байт, нагрузка на диск на 4 порядка меньше так что он не становится узким звеном

Добавлено:

Цитата:

однако в диспетчере задач пишет 270мб под конец

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


Цитата:

у меня не распаковываются файлы запакованные srep 2.98 alpha
если файл больше 2 гб то не распаковывается

да, 32-битные версии srep имеют такую ошибку. спасибо!

раскладку я уже приводил:

srep - gcc
srep32/64 - msvc
srep32i/64i - icl



Добавлено:

Цитата:

однако в диспетчере задач пишет 270мб под конец

а, сообразил - это скорей всего из-за mmap. попробуй -nommap; вероятно в gcc-версии mmap просто не срабатывает

Bulat_Ziganshin
Цитата:

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

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


Цитата:

а, сообразил - это скорей всего из-за mmap. попробуй -nommap; вероятно в gcc-версии mmap просто не срабатывает

большое кол-во памяти потребляют (у меня уж точно, правда зависит от файла) все варианты srep/32/32i, флаг nommap всех их ограничивает в той, которая указана в mem req

я про lzf спросил потому что не сталкивался с теми случаями когда память тратится много, однако только что я запаковал архив (dbf-файлы) с lzf и при распаковке увидел что память он нехило тратит, теперь понятно к чему было написано

Цитата:

- Таким образом, мы можем распаковать 22 ГБ файл с 2 ГБ ОЗУ, или даже с 200 МБ ОЗУ и 2 ГБ VM файле, и скорость остается очень высокой, около 100 МБ/с! Я считаю, что это выдающийся результат.

получается зависит от кол-ва lz math

Цитата:

кстати и теперь через arc\freearc не пашет, только вариант без -f пашет потому что я разделил srep

а вот этого я не понял


Добавлено:

Цитата:

я смотрю столбик память, есть еще вирт. память, но указанная вам "выделенная память" отсутствует

ах да, у меня win7, поэтому названия другие. но всё равно столбец какой-то другой, может вирт. память. то что он до 100 мб сбрасывается при минимизации - это уже о многом говорит, наверно это физ. память выделенная в данный момент проге


Цитата:

получается зависит от кол-ва lz math

зависит от общего объёма "отложенных на будущее" данных. я на английском форуме помнится даже график приводил для этого 22 гб файла

да точно вирт память это

Цитата:

а вот этого я не понял

Цитата:

[External compressor:srep]
;options = l%d (minimal match length, default=512)
packcmd = srep {options} $$arcdatafile$$.tmp - <stdout>
unpackcmd = srep -d - - <stdin> <stdout>

[External compressor:srep_f]
;options = l%d (minimal match length, default=512)
packcmd = srep {options} -f - - <stdin> <stdout>
unpackcmd = srep -d - - <stdin> <stdout>

кстати кажется в распаковку лучше добавить {options} чтобы ограничить память или еще какие нибудь параметрыы исп-лись при распаковке

kalpak

Цитата:

кстати кажется в распаковку лучше добавить {options} чтобы ограничить память или еще какие нибудь параметрыы исп-лись при распаковке

последние рекомендации тут http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=620#2

Добавлено:

Цитата:

я на английском форуме помнится даже график приводил для этого 22 гб файла

картинки тут http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=240#11

Цитата:

оказывается что по умолчанию в normal preset match finder - ht4 ?

да. попробуй поищи в топике по "ht4", это апрель 2009-го afair


Цитата:

для tor в исходниках вроде написано что  он принимает параметры многие, например  p(parser ),

из help'a:

-p# -- parser (1-greedy,2-lazy), default 2

другие парсеры планировались, но так и не были реализованы. вообще tor интересен только для быстрого сжатия, иначе lzma круче



Цитата:

а нельзя сделать чтобы архиватор при распаковке архива с методом 4x4 (например lzma:128mb:fast:96:mc20) учитывал параметр t (кол-во потоков), для данного файла ставил t2
а то получается смешная ситуация, запаковать смог, а распаковать нет ))
(использовался архиватор 0.666 build)
можно даже не указывать кол-во потоков, он все равно сможет запаковать, получается опция lc75p по-умолчанию работает, а опция ld75p - нет
 
кстати unarc успешно его распаковывает
(067 alpha 2011-03-18, 0.666 зависала [ошибки не было, просто нечего не делала])

запутался я в твоих показаниях...

Цитата:

запутался я в твоих показаниях...

был файл 8гб, я его запаковал с 4x4:t2:lzma:128mb:128:mc10 (если т2 не указать, то памяти не хватит и ошибка выйдет)
но сохраняет он информацию что сделан архив 4x4:lzma:128mb:128:mc10
и пишет что для распаковки надо больше 2гб памяти ( у меня лог. 4 потока)
т.е. получается что указать сколько потоков нужно для упаковки можно, а какое кол-во было указано не сохраняется в методе сжатия и он просто пытается задействовать все потоки
unarc успешно его распаковывает (067 версия), а FA жалуется что памяти не хватает
кстати а кол-во блоков в методе 4х4 чем то ограничено? у меня разница между xlzma и lzma около 50 мб (тот же файл 8гб), как я не пытался сделать блок большим

kalpak
это всё без lc/ld? пиши чётко - команда (проще даже лог с экрана), конфиг компа, и что по твоему не так работает

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

Добавлено:
кстати, пришёл в голову трюк, который возможно способен на порядок ускорить распаковку обычного srep (без -f) когда идёт трешинг диска - считывать матчи параллельно в нескольких десятках потоков. тогда есть надёжда что сработает ncq и мы будем иметь qd=32 or so

Bulat_Ziganshin
вот я пакую файл
[more=подробнее]
Цитата:

C:\>arc a --cache=16mb -di -i2 -m4x4:lzma:256mb:fast data.arc "D:\Alcohol 120%\X
AKEP_10_82_DVD.md0"
FreeArc 0.67 (November 17 2010) Creating archive: data.arc using 4x4:i0:lzma:256
mb:fast:32
Memory for compression 1410mb, decompression 1154mb, cache 16mb
Compressing 1 file, 365,887,488 bytes
Compressing Alcohol 120%\XAKEP_10_82_DVD.md0
Compressed 1 file, 365,887,488 => 325,278,312 bytes. Ratio 88.9%
Compression time: cpu 366.06 secs, real 329.84 secs. Speed 1,109 kB/s
All OK

я так понял он архиватор все таки смог запаковать тем методом, который я написал (опция lc по умолчанию сработала, я нечего не писал)
однако при распаковке

Цитата:

D:\free_arc067\bin>arc x -ld75% c:\data.arc
FreeArc 0.67 (March 18 2011) extracting archive: c:\data.arc
Extracting 1 file, 365,887,488 bytes. Processed 0.0%
ERROR: can't allocate memory required for (de)compression in 4x4:lzma:256mb:fast
:32

D:\free_arc067\bin>arc x -ld95p c:\data.arc
FreeArc 0.67 (March 18 2011) extracting archive: c:\data.arc
Extracting 1 file, 365,887,488 bytes. Processed 0.0%
ERROR: can't allocate memory required for (de)compression in 4x4:lzma:256mb:fast
:32

D:\free_arc067\bin>arc x c:\data.arc
FreeArc 0.67 (March 18 2011) extracting archive: c:\data.arc
Extracting 1 file, 365,887,488 bytes. Processed 0.0%
ERROR: can't allocate memory required for (de)compression in 4x4:lzma:256mb:fast
:32

D:\free_arc067\bin>

[/more]

в GUI пишет что для упаковк нужно ~2450mb для упаковки и ~2300 для распаковки
[more=рисунок] [/more]
я забыл написать t1 при упаковке, но вот только что сделал с т1 и результат такой же.
[more=подробнее]
Цитата:

C:\>arc a --cache=16mb -di -i2 -m4x4:t1:lzma:256mb:fast data2.arc "D:\Alcohol 12
0%\XAKEP_10_82_DVD.md0"
FreeArc 0.67 (November 17 2010) Creating archive: data2.arc using 4x4:t1:i1:lzma
:256mb:fast:32
Memory for compression 1217mb, decompression 1153mb, cache 16mb
Compressing 1 file, 365,887,488 bytes
Compressing Alcohol 120%\XAKEP_10_82_DVD.md0
Compressed 1 file, 365,887,488 => 325,278,312 bytes. Ratio 88.9%
Compression time: cpu 337.91 secs, real 359.48 secs. Speed 1,018 kB/s
All OK
C:\>

при распаковке

Цитата:

D:\free_arc067\bin>arc x -ld75p c:\data2.arc
FreeArc 0.67 (March 18 2011) extracting archive: c:\data2.arc
Extracting 1 file, 365,887,488 bytes. Processed 0.0%
ERROR: can't allocate memory required for (de)compression in 4x4:lzma:256mb:fast
:32

D:\free_arc067\bin>arc x -ld75p c:\data2.arc

[/more]

только чтот-о я не могу распаковать их unarc, странную ошибку пишет
[more=лог]
Цитата:

D:\>unarc x c:\data2.arc
FreeArc 0.67 unpacker. Extracting archive: data2.arc
Extracting Alcohol 120%\XAKEP_10_82_DVD.md0 (365887488 bytes)

ERROR: archive data corrupted (decompression fails)
D:\>unarc x c:\data.arc
FreeArc 0.67 unpacker. Extracting archive: data.arc
Extracting Alcohol 120%\XAKEP_10_82_DVD.md0 (365887488 bytes)

ERROR: archive data corrupted (decompression fails)
D:\>

[/more]
система: win xp sp2 ram 2gb | core 2 duo e4400
на работе система: win xp sp3 ram 2gb | core i5 650

Цитата:

кстати, пришёл в голову трюк, который возможно способен на порядок ускорить распаковку обычного srep (без -f) когда идёт трешинг диска - считывать матчи параллельно в нескольких десятках потоков. тогда есть надёжда что сработает ncq и мы будем иметь qd=32 or so

а если жесткий диск не поддерживает ncq то что делать ?))
что такое qd=32 or so ?

Цитата:

а если жесткий диск не поддерживает ncq то что делать ?))

тогда он будет работать с прежней скоростью


Цитата:

что такое qd=32 or so ?

or so="или типа того". qd - глубина очереди запросов, если долбить диск из 32 потоков, то qd будет 32 и диск с ncq получит шанс переупорядочить запросы, а диск без ncq просто выполнит их по очереди, как и сейчас


Цитата:

вот я пакую файл

теперь ясно. будем искать

Добавлено:

Цитата:

в GUI пишет что для упаковк нужно ~2450mb

кста на будущее есть команда lt:

[more=подробнее]
Цитата:

C:\Tests> Arc.exe lt ArcShellExt.arc
FreeArc 0.67 (March 18 2011) listing archive: ArcShellExt.arc

Archive type: FreeArc
Total bytes: 965,349
Compressed bytes: 965,350
Ratio: 100.0%

Directory blocks: 1
Directory, bytes: 457
Directory, compressed: 275
Solid blocks: 2
Avg. blocksize: 471 kb

Compression memory: 450 mb
Decompression memory: 450 mb
Dictionary: -

Archive locked: -
Archive comment: -
Recovery info: -
SFX size: -
Headers encrypted: -
Encryption algorithms: -

Pos Size Compressed Files Method
-----------------------------------------------------------------------------
31 0 0 1 storing
31 965,349 965,350 10 paq8px64
-----------------------------------------------------------------------------
11 files, 965,349 bytes, 965,350 compressed

[/more]

Bulat_Ziganshin
понятно, буду знать )
а вот насчет ошибка распаковки unarc странно, на работе у меня получалось распаковывать

SREP 2.99 release candidate:

fixed bug: 32-bit version was unable to decompress large files (>2gb) compressed with -f


btw, i've tested srep on i7-2600k@4.6GHz - compression speed on my files was in 100-200 mb/s range so srep was ALWAYS limited by HDD speed

Добавлено:


and once again: -nommap testing proves that memory-mapped files slow down the SREP when you are short on RAM:


Код: D:\>read lp2.pcf
Speed 84.369956 mbytes/sec

srep64i -m1 Cpu 148.074 mb/sec, real 83.986 mb/sec

srep64i -m2 Cpu 201.726 mb/sec, real 54.300 mb/sec
srep64i -m2 -nommap Cpu 209.772 mb/sec, real 71.276 mb/sec

srep64i -m3 Cpu 155.684 mb/sec, real 40.795 mb/sec
srep64i -m3 -nommap Cpu 157.294 mb/sec, real 57.553 mb/sec

Compression ratio: 22,069,494,174 -> 7,284,431,814: 33.01%

Bulat_Ziganshin

Цитата:

tested srep on i7-2600k@4.6GHz

главное не указали, кол-во RAM

16 Gb.

ага, но 5 гиг рамдиском занято

тест на SSD Intel G2 120gb


Код: C:\>read lp2.pcf
Speed 236.023188 mbytes/sec

srep64i -m1 Cpu 154.174 mb/sec, real 146.101 mb/sec

srep64i -m2 Cpu 223.845 mb/sec, real 100.994 mb/sec
srep64i -m2 -nommap Cpu 227.554 mb/sec, real 167.256 mb/sec

srep64i -m3 Cpu 179.942 mb/sec, real 96.754 mb/sec
srep64i -m3 -nommap Cpu 166.436 mb/sec, real 86.298 mb/sec