Sonar 8.3.1: не отключается кэширование чтения с диска

[Mastero]

Сегодня запустил Сонар, загрузил проект, включил воспроизведение и обнаружил фоновый, так сказать, треск и скрежет регулярного характера.
Немного подумав и проведя несколько небольших экспериментов, пришёл к выводу, что кэширование чтения с диска почему-то не отключается, хотя галочка в соответствующем чекбоксе НЕ установлена.
Треск и скрежет возникают как раз при обращении к диску за очередной порцией для кэширования.
Удалил Aud.ini, установил более новую версию драйверов на аудиокарту, дефрагментировал диск, скопировал аудио-данные на другой диск и попробовал запустить с него.
Проблема не решилась. Кто сталкивался уже с таким глюком? Кто что посоветует?

Вот содержимое AUD.INI:

[Aud]
DataDir=C:\Cakewalk Projects\Audio Data
PictureDir=C:\Cakewalk Projects\Picture Cache
PicCacheMB=500
PicCacheZoom=128
PicCacheLevels=2
EnablePicCacheThreads=1
ComputePicturesWhilePlaying=1
CopyOnImport=1
ReadCache=0
WriteCache=0
EnableCacheWriteThru=1
VolMethod=1
PanMethod=1
DiskBufSize=256
DiskRecBufSize=256
ExtraDiskBuffers=2
DitherAlgorithm=2
ZeroFillMethod=2
RecordPreAllocSeconds=0
ZeroFillDB=300
FlushWriteBeforeRead=0
FlushMultiple=1
DefaultEqPosition=0
DefaultAudSnapOfflineStretchMethod=3
DefaultAudSnapOnlineStretchMethod=5
RealtimePreroll=0
SuspendPluginsOnBounce=1
[Wave]
DefaultSampleRate=48000
DriverID=0
WaveInID=0
OpenInputFirst=0
SmpteMode=1
TimingOffsetMsec=0,000000
TimingOffsetBuffers=0
LatencyMsec=1
BounceBufSizeMsec=0
FlushOnStop=1
ThreadSchedulingModel=1
EnableMixThreads=1
MixThreadCount=0
EnableSetThreadIdealProcessor=1
AllowOfflineRenderMixThreads=1
UseMMCSS=1
MMCSSThreadPriority=2
MMCSSTaskKey=Pro Audio
FreeMemOnUnload=1
AlwaysOpenAllDevices=0
MinimizeDriverStateChanges=1
RemoveDCOffset=0
EnableAsioBufferSwitchTimeInfo=1
EnableDeviceOutputLatencyCompensation=1
UseHardwareSamplePosition=1
BitsPerSample=24
FileBitDepth=16
RenderBitDepth=32
ImportBitDepth=0
ExtraPluginBufs=0
MixDezipperUsec=50
GapDezipperUsec=500
WaveInBuffers=8
WaveOutBuffersMME=4
WaveOutBuffersKS=2
MeterFrameSizeMS=40
SyncMaxDriftMsec=2
SyncDivisor=8
ProfiledMME=0
ProfiledKS=1
ProfiledWASAPI=0
UseWDMDmaForWASAPI=1
LinkSendPan=0
LinkPFSendMute=0
StopOnEmptyPlayQueue=0
KsUseInputEvent=0
WaveOutExtraBuffers=1
AutomationDecimationMsec=50
EnableSSEMixing=1
ThumbnailCacheSize=100
ManageASIOThreadPriority=1
EnableLiveADCRecalc=1
UseAlias=0
DropoutMsec=250
StartFadeMsec=0
StopFadeMsec=0
PanLaw=0
DisableIMDuringPlay=0
ShowMultiChannelInputs=1
ShowMultiChannelOutputs=1
[M-Audio Delta Audiophile (3 in, 2 out)]
MigratedDMA=1
Name=Delta AP 1/2
InputLatencyOffset=0
UseAsioReportedLatency=1
WidePacking=4
Interleave=2
Use24BitExtensible=0
UseExtensibleForMultiChannelIO=1
WDM.DMA.11025=11 11 11 11
WDM.DMA.22050=22 22 22 22
WDM.DMA.44100=128 256 128 256
WDM.DMA.48000=128 256 128 256
WDM.DMA.88200=128 256 128 256
WDM.DMA.96000=128 256 128 256
WDM.DMA.176400=176 176 176 176
WDM.DMA.192000=192 192 192 192
[Debug]
TraceISR=0
RecBufFill=0
SpinDumpBreak=1
SpinTimeDumpUsec=0
SpinTimeTransDumpUsec=0
[DriverMap.WDM]
UseWaveOut1=1
UseWaveOut2=1
UseWaveIn1=1
UseWaveIn2=1
UseWaveIn3=1
[SampleRates]
Count=8
0=11025
1=22050
2=44100
3=48000
4=88200
5=96000
6=176400
7=192000

 

[P00H]

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

откуда? из аудиовыходов карты или из системного блока?

 

[Mastero]

откуда? из аудиовыходов карты или из системного блока?

из аудиовыходов карты. Как их собирательно называют — «pops, clicks and scratches».
Тот физический диск, с которого идёт чтение аудио-файлов, разделён на 3 логических диска. На других разделах 9 бэд-секторов. Но я попробовал сегодня грузить аудио-файлы с другого диска, история та же. Значит дело в Сонаре?

 

[Elle]

попробуй поварьировать параметры Playback/Record I/O Buffer Size в обе стороны: как меньше (128, 64), так и больше (512, 768, 1024).
согласно aud.ini кэширование у тебя отключено

и ещё, раньше подобных проблем не было что ли? вот так неожиданно раз и трещало? каков объём RAM? может просто банально не хватает памяти для данного проекта?

 

[Akula Alex]

Зачастую треск может вызывать какой-нибудь глюкнувший
плагин, пробовал отключить все эффекты?

Latency звуковой карты пробовал увеличивать?

 

[Mastero]

попробуй поварьировать параметры Playback/Record I/O Buffer Size в обе стороны: как меньше (128, 64), так и больше (512, 768, 1024).

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

согласно aud.ini кэширование у тебя отключено

да. А вот на самом деле оно включено.

и ещё, раньше подобных проблем не было что ли? вот так неожиданно раз и трещало? каков объём RAM? может просто банально не хватает памяти для данного проекта?

В июне Сонар не включал ни разу :beach:

Раньше никогда подобной проблемы не было. Оперативки 2 Гига. Пробовал в нескольких проектах, в т. ч. и мало загруженных.

Возможно, какая-либо другая программа (типа Norton WinDoctor) что-то «поправила» в сонаровских файлах по своему усмотрению.

 

[Mastero]

Зачастую треск может вызывать какой-нибудь глюкнувший
плагин, пробовал отключить все эффекты?

Да, без толку. скрэтчи идут при воспроизведении простого аудио.

Latency звуковой карты пробовал увеличивать?

Увеличивал и задержку и кол-во буферов. При увеличении задержки в 4 раза никаких изменений. При увеличении буферов с 2 до 10 треска поубавилось, но совсем он не исчез.
И это в WDM-режиме!
При переключении в ASIO скрежет усиливается в несколько раз.

 

[Elle]

да. А вот на самом деле оно включено.

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

Раньше никогда подобной проблемы не было. Оперативки 2 Гига. Пробовал в нескольких проектах, в т. ч. и мало загруженных.

что подразумевается под малозагруженными? Скажем, елси я открою абсолютно пустой новый проект, импортирую в него одну аудиодорожку (ну, например, рипнуый трэк с компакт-диска) и нажму кнопку воспроизведения - щелчки будут? Если нет, то при каком количестве подобных и разных по содрежанию дорожек (т.е. ссылающихся на разные аудиофайлы) начинаются проблемы? как при этом ведёт себя сонаровский HDD Meter (он рядом с CPU измерителем находится)?

Возможно, какая-либо другая программа (типа Norton WinDoctor) что-то «поправила» в сонаровских файлах по своему усмотрению.

в сонаровских файлах - это скорее из области фантастики. А вот сбить какие-то тонкие и недоступные обычному пользователю настройки ОС - запросто. Попробуйте, кстати, отключить всякие антивирусы и прочее ПО, которое может вызывать интенсивную дисковую активность.

ЗЫ:
кстати, учитывая факт наличия дефектов поверхности (9 бэд секторов), хотелось бы уточнить, на каком жёстком диске находится системный swap-файл?

 

[Mastero]

Вы хоть знаете, что такое кэширование вообще? Сможете объяснить простыми словами?

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

Касательно Сонара никогда до этого случая не задумывался особо — что и какими способами он кэширует.

Но, если взглянуть на характеристику современного жёсткого диска, то становится понятно, что кэширование при работе в Сонаре необходимо. Вот взгляните, например: http://market.yandex.ru/model.xml?hid=91033&modelid=2411905&clid=502

Среднее время доступа, чтение 8.5 мс
Среднее время доступа, запись 9.5 мс
Среднее время задержки (Latency) 4.16 мс

У меня в Сонаре задержка выставлена в 2,7 мс (128 сэмплов).

Следовательно, воспроизведение без кэширования невозможно?

как при этом ведёт себя сонаровский HDD Meter (он рядом с CPU измерителем находится)?

Как раз таки нормально. А вот измеритель загруженности CPU показывал иногда 150%.

Попробуйте, кстати, отключить всякие антивирусы и прочее ПО, которое может вызывать интенсивную дисковую активность.

В антивирусе и файрволе на моём компе все рабочие папки Сонара стоят в списке исключений.

---
Вобщем проблема треска решилась. Я убрал из системы диск со сбойными секторами, заменил его на полностью нормальный.
Отключил в BIOS контроль SMART-параметров HDD.
Систему откатил до состояния на 17 июня 2009.

Запустил Сонар и всё стало работать стабильно.

Но вопрос о неотключаемом кэшировании всё же остался , т. к. с галочкой и без галочки чтение с диска идёт одинаковое. Значение у меня выставлено в 256 килобайт.

 

[tarzan]

с галочкой и без галочки чтение с диска идёт одинаковое

Может быть и такой вариант, что Сонар тут не при чем (раз галочка не влияет) и кэширование чтения с диска тоже не причем. Надо искать виновника, это может быть и вирус и что угодно.

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

Кстати, 2,7 мс - это очень приличная нагрузка на проц.

 

[CakeWorker]

измеритель загруженности CPU показывал иногда 150%.

с галочкой и без галочки чтение с диска идёт одинаковое.

Фантастика, прямо... Хотя, нонсенс - более подходящее определение.

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

В антивирусе и файрволе на моём компе все рабочие папки Сонара стоят в списке исключений.

В работе с музонами задействованы далеко не только папки ТОЛЬКО Сонара. Функционирование антивируса сказывается на всей системе. И отключать его - дааалеко не просто чья-то "пустая" рекомендация.

 

[P00H]

Но вопрос о неотключаемом кэшировании всё же остался , т. к. с галочкой и без галочки чтение с диска идёт одинаковое.

windows тоже кэширует диски если это не отключено в свойствах

 

[Elle]

Касательно Сонара никогда до этого случая не задумывался особо — что и какими способами он кэширует.

а стоило бы, потомучто всё, что вы всё смешали в такую кашу, что... даже слов нет

1. Галочки для включения кэширования, как уже отметил CakeWorker, предназначены для древнейших жёстких дисков, у которых и кэша-то аппаратного, может, как такового не было. Речь идёт об IDE дисках, не работающих даже с DMA. Что уж говорить про UDMA. И что уж говорить про нынешние SATA, у которых по 16-32 МБ кэша просто встроено и управляется аппаратным образом, а уж если ещё и с NCQ...
Так что про эти галочки можете забыть как про страшный сон, однажды их отключив. Их включение вынуждает сонар своими силами, но опираясь на подсистему кэширования ОС, организовывать кэширование данных с жёсктого диска. Я вообще удивляюсь, для чего галки эти оставили, в наше-то время..

2. Playback/Record I/O Buffer Size вообще никакого отношения к кэшированию не имеет. ВООБЩЕ НИКАКОГО!!! Фактически эти величины задают размер "порции" для общения с жёстким диском. К лэйтенси/задержке это тоже имеет ровно такое же отношение, как, скажем, воробей к утюгу. Всё на что влияет Playback/Record I/O Buffer Size представляет из себя лишь пропускную способность, своего рода ширину канала между диском и аудио в реальном времени. При работе с высокими частотами дискретизации и высокой битностью (от 88.2/32) рекомендуют увеличить размер этих буферов, так как объём данных в единицу времени тоже увеличивается (по сравнению скажем с 44.1/32)

3. О воспроизведение без кэширования:
кэш - это вообще-то не просто кусок памяти, в который данные считываются с жёсткого диска при воспроизведении, чтоб потом уже оттуда попасть в память звукового редактора. Зачем, если б можно было сразу на прямую с диска в память редактора, не так ли?
Так что суть кэша совсем в другом - в том, что в него попадают далеко не все данные, а только те, которые, согласно определённому алгоритму, считаются наиболее "популярными". Т.е. кэш пытается хранить в себе только такие данные, которые запрашиваются с жёсткого диска по той или иной причине чаще всего.
Например работаете вы над проектом с 10-ю аудиотрэками. Играете регулярно пару тактов, чтоб послушать/подкорректировать обработку/сведение. Разумеется при каждом новом воспроизведении этих двух тактов данные с жёсткого диска заново считываться не будут, ну, по крайней мере частично - факт, так как они как раз-таки попадут в кэш за свою "популярность". Но стоит вам переткнуться в другой конец проекта и запустить воспроизведение там, как кэш мгновенно придёт в негодность, пока снова не адаптируется к этим новым двум тактам в другом конце проекта.
Да, безусловно, переход к абсолютно новой порции данных, т.е. к аннулированию большинства записей в кэше, может вызвать задержку между нажатием на кнопку Play мышкой и непосредственно началом воспроизведения. Но это задержка совершенно иного характера и никакого отношения к latency звуковой карты не имеет. Если немножко поразмыслите серым веществом, может даж это сами осознаете.

4. Ещё раз о воспроизведении без кеширование ЛОЛ:
в конечном итоге, воспроизведение без кэширования действителньо невозможно, так как современные жёсткие диски занимаются кэшированием независимо от вашего желания и при этом для вашего же блага. Но, ещё раз, никакого отношения больше это ни к чему не имеет: ни к лэйтенси, ни к чему бы то ни было ещё. А тот факт, что отключение/включение галочек ни на что не влияет, во-первых, не подтверждён объективно и является лишь вашим субъективным впечатлением, а, во-вторых, не смотря на во-первых вполне правдоподобен, так как галочки эти к современным жёстким дискам не применимы. Но в общем случае, если исходить из принципа оптимальных настроек, галочки лучше эти снять, так как их включение, вообще говоря, активирует выполнение дополнительной части кода программы и его взаимодействия с ОС. Так что не стоит этим злоупотреблять.

5. SMART бы я на вашем месте отключать не стала.. он всё-таки не такой глупый, чтоб просто так тесты запускать, когда ему вздумается. А вот заранее оповестить о появившейся проблеме может.. это я вам говорю, как несчастаня владелица Seagate ES.2. Так что если у вас тот самый сигейт 7200.11, что вы привели на ссылке, то сбэкапьте с него важные данные - не придётся потом тратиться на восстановление.


На этом, извините, на сегодня всё. Концерт окончен, клоуны разъехались, и батарейка у меня с вами села))))

 

[Banson]

ELLE, ты молодец. Популярно и терпеливо :moil:объяснила простые вещи и некоторым утерла нос. Иногда, действительно, топики совсем для маленьких, но на то и форум.

 

[Akula Alex]

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

Обалдеть! И после этого ты хотел, чтоб ничего не трещало?
Сразу не мог сказать , что жесткий диск битый?

 

[Mastero]

windows тоже кэширует диски если это не отключено в свойствах

А ведь и точно! Это кэширование уже нельзя обойти. А если его отключить, то скорость обмена данными с жёстким диском значительно снизится.

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

Я вообще удивляюсь, для чего галки эти оставили, в наше-то время..

Значит будем считать их атавизмом.

Сразу не мог сказать , что жесткий диск битый?

На логическом разделе, с которым работал Сонар, битых секторов не было. Они были на других разделах этого диска.

Playback/Record I/O Buffer Size вообще никакого отношения к кэшированию не имеет. ВООБЩЕ НИКАКОГО!!! Фактически эти величины задают размер "порции" для общения с жёстким диском.

И фактически это место в оперативной памяти, т. е. временный буфер, или кэш. А как же иначе?

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

Вообще, конечно, теперь я понимаю, что название этого топика звучит глупо. Просто я запаниковал тогда из-за этих помех в звуковом тракте.
Но если здраво поразмыслить, то можно уже насчитать 3 кэша: кэш HDD, кэш OS и кэш Playback/Record I/O Buffer (т. к. Сонару позволено обращаться к HDD напрямую).
И теперь я осознал, что все эти кэши должны работать.

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

Меня SMART ни разу заранее о проблеме не оповещал. А всегда только ставил уже перед фактом. Тем более, я отключил его в BIOS, но LDCM Hard Disk Sentinel продолжает контролировать параметры.
Зато теперь при резервном копировании прогой Acronis true Image нет внезапных отключений компа.

Собственно, программой, приведшей к сбою работы Сонара, была, скорее всего, утилита от Seagate — SeaTools. Будьте внимательны при её установке и использовании!

Так что если у вас тот самый сигейт 7200.11, что вы привели на ссылке, то сбэкапьте с него важные данные - не придётся потом тратиться на восстановление.

Я как раз непосредственно до установки SeaTools изучал проблему этой серии Seagate.
Сейчас три из четырёх дисков в моём компе — как раз этой серии. Но в «группе риска» общей проблемы серии — только один.
А от сбоев ни один диск не застрахован.

 

[Elle]

фактически это место в оперативной памяти, т. е. временный буфер, или кэш. А как же иначе?

гмм.. это можно расценивать как троллинг?
ещё раз, чёрным по белому, кэш и буфер - это принципиально разные понятия! единственное, что их объединяет - это то, что и то, и другое - это некоторый объём памяти. Но на этом сходства заканчиваются. Соизвольте почитать хотя бы на русской вики, что такое кеш, а также как, почему, и какими данными он заполняется. Это не просто какой-то буфер, непрерывный поток данных в который сваливается, например, одним процессом, а затем вычитывается другим.
Так что Playback I/O Disk Buffer никакого отношения к термину кеш не имеет.

На логическом разделе, с которым работал Сонар, битых секторов не было. Они были на других разделах этого диска.

Вы думаете, что во время работы сонара к диску больше ни одна живая душа не обращается? Да там один pagefile чего стоит. К тому же вы точно подметили, что диск с данными проекта и сонаром именно логический. Физически это всё равно одно и то же устройство, поэтому проблемы в любом его физическом секторе могут сказаться на производительности логически здоровых разделов. Более того, наверняка треск был связан с тем, что процессор банально подвисал на операции чтения/записи в ожидания завершения оной, из-за чего вы и получали ваши 150%, и, как следствие, треск.

SeaTools

эта утилита кроме пары простеньких тестов вобще делать ничего не умеет.. так что я сомневаюсь, что она могла своей работой повлиять на сонар. Работайте с аппаратурой без дефектов - это залог стабильности.

 

[Mastero]

гмм.. это можно расценивать как троллинг?

В той же Википедии написано:

Буфер и Кэш
Эти термины не являются взаимоисключающими, и их функции часто смешиваются, но существует различие в их предназначении.

http://ru.wikipedia.org/wiki/Буфер_(информатика)

 

[Elle]

В той же Википедии написано:
http://ru.wikipedia.org/wiki/Буфер_(информатика)

так я вроде не писала, о том, что это понятия взаимоисключащие, не так ли? перечитайте внимательно ещё раз:

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

поэтому, если вы не понимаете, о чём идёт речь... а вы либо действительно не понимаете, либо пишете здесь только с целью поспорить и настоять на своём (что по сути флуд и троллинг и что, в общем-то, при этом не исключает вашего непонимания)... то запомните тот факт, что буфер и кеш - это концептуально разные понятия. И служат они совершенно для разных целей.
И я это пишу не с целью настоять на своём и доказать свою правоту, а для того, чтоб у вас же самих убрать кашу в голове. Вы же не называете ДВД-диск или флэшку буфером, не так ли? Хотя в зависимости от их использования - это было бы вполне правоместно. Просто так уж получилось, что их изначально используют с несколько иной целью. Да, пример не самый удачный, но, надеюсь, что хотя бы показательный. Так что давайте всё-таки ДВД-диски называть ДВД-дисками, флэшки - флэшками, кеш - кешем, а буфер - буфером.

 

[Mastero]

Я не собираюсь спорить, вот здесь толково написано: http://en.wikipedia.org/wiki/Cache#The_difference_between_buffer_and_cache

The difference between buffer and cache

The terms are not mutually exclusive and the functions are frequently combined; however, there is a difference in intent. A buffer is a temporary memory location, that is traditionally used because CPU instructions cannot directly address data stored in peripheral devices. Thus, addressable memory is used as intermediate stage. Additionally such a buffer may be feasible when a large block of data is assembled or disassembled (as required by a storage device), or when data may be delivered in a different order than that in which it is produced. Also a whole buffer of data is usually transferred sequentially (for example to hard disk), so buffering itself sometimes increases transfer performance. These benefits are present even if the buffered data are written to the buffer once and read from the buffer once.

A cache also increases transfer performance. A part of the increase similarly comes from the possibility that multiple small transfers will combine into one large block. But the main performance gain occurs because there is a good chance that the same datum will be read from cache multiple times, or that written data will soon be read. A cache's sole purpose is to reduce accesses to the underlying slower storage. Cache is also usually an abstraction layer that is designed to be invisible from the perspective of neighbouring layers.

Вы же не называете ДВД-диск или флэшку буфером, не так ли? Хотя в зависимости от их использования - это было бы вполне правоместно

Если диалектически помыслить, то та же самая USB-флэшка может быть в различных ситуациях как буфером, так и кэшем!
Например, мы записали на неё несколько миди-файлов аранжировок, сделанных на своём компьютере.
Если мы сидим за этим же компьютером, и нам срочно нужно воспользоваться этими файлами, то мы не обращаемся к флэшке, а отправляемся сразу к компьютеру, там они уже есть (как правило). Флэшку-буфер мы не используем.
А вот если мы с этой флэшкой приехали к другу, живущему в другом районе города, то за миди-файлами мы обращаемся уже к флэшке. В этом случае флэшка, как ближайший носитель этих файлов, служит уже кэшем. :smile:

 

[Elle]

Mastero,
вот честно, диалектики не поняла...
т.е. основная-то идея понятна, и я в том числе её и пыталась донести: как кусок памяти не назови, куском памяти, с присущей ей функциональностью, он от этого быть не перестанет
вот только названия буфер и кеш накладывают на такой кусок памяти своё индивидуальное предназначение и свою индивидуальную функциональность. Если вы немножко знакомы с ООП, то "буфер" и "кеш" можно рассматривать как дочерние классы, унаследованные от класса "кусок памяти".
ну да ладно, не будем о грустном.. я вот вам пример придумала, без всяких флешек и ДВД. Надеюсь, что показательный.

Итак, представим, что у нас есть 2 города, А и Б. Они соединены между собой железкой, по которой ходит поезд.

Буфер:
Предположим, что поезд идёт из пункта А в пункт Б 30 минут. Ну и соответственно столько же в обратную сторону. Т.е. путешествие туда и обратно займёт ровно час.
Теперь представим, что каждые 5 минут на платформе в пункте А появляется порция товара для транспортировки. Причём одновременно на платформу по тем или иным обстоятельствам вмещается только одна такая порция. Т.е. к платформе подъезжает машина, смотрит, свободна ли платформа и, если свободна, выгружает товар на платформу. А если не свободна, то уезжает, так ничего и не разгрузив.
Поезд способен одновременно везти до 10 порций товара.
Вопрос - как эффективнее (быстрее и больше) перевезти товар из одного города в другой?
предлагается 2 варианта решения:
1)

{
  загружаем порцию товара с платформы;
  отправляем поезд;
  ждём его возвращения;
  повторяем с начала;
}

2)

{
  пока поезд не полон
  {
    загружаем порцию товара с платформы;
    ждём 5 минут;
  }
  отправляем поезд;
  повторяем с начала;
}

Оценка эффеткивности решения:
1) для транспортировки 10 порций потребуется 10 часов (10 раз съездить туда и обратно)
2) для транспортировки 10 порций потребуется 1 час 50 минут (5*10=50 минут на загрузку поезда 10 порциями) и 1 час требуется поезду доехать туда и обратно.

Кеш:
Пусть в нашем поезде по-прежнему 10 вагонов. И он по-прежнему возит товар из пункта А в пункт Б. По-прежнему за 30 минут.
Всего существует 10 видов различных товаров (для простоты будем считать, что они все одинакового объёма), перевозимых из А в Б.
В городе Б для каждой транспортировки делают заказ, что именно привезти. В целом можно сказать, что выборка видов перевозимого товара достаточно равномерно распределена. Т.е. при каждой транспортировке поезд может быть набит чем угодно.
Однако, догадливый машинист с высшим математическим образованием заметил, что условиям задачи безоговорочно верить нельзя и в течение нескольких перевозок вёл статистику, что именно он каждый раз везёт. И заметил, что так или иначе парочка товаров пользуется особой популярностью. Тогда, машинист, недолго думая, прицепил ещё один вагончик к составу, и стал его загружать тем самым популярным товаром. Так чтоб в следующий раз, когда в городе Б потребуются эти 2 товара, им не пришлось бы ждать как минимум полчаса.
Прошло полгода, наступила зима, потребности в городе Б изменились, и машинист, который продолжал аккуратно вести статистику перевозимого товара, изменил наполнение дополнительного 1 вагона.


Ну что, теперь понятно где буфер, а где кеш?
А ведь заметьте в обоих случаях речь шла о вагонах и товаре, в них перевозимом. И как эти вагоны не называй, всё равно можно будет загружать их товаром и разгружать.
Надеюсь, теперь-то уж я донесла до вас мысль)))

ЗЫ: прошу прощения за такой оффтопик.. но не удержалась)))))

 

[Mastero]

Ну что, теперь понятно где буфер, а где кеш?

спасибо, это очень показательный пример.
Тогда настройку в Сонаре «playback (record) I/O buffer size» можно считать «чистым» буфером? Без примеси «кэшевых вагонов»?