Конференция работает на сервере Netberg

Radeon.ru

Конференция Radeon.ru

Страница 80 из 113 [ Сообщений: 4488 ]  Версия для печати [+] На страницу Пред.  1 ... 77, 78, 79, 80, 81, 82, 83 ... 113  След.
Показать сообщения за  Поле сортировки  
McZag
В основном из общих соображений. Это нормально. Сделать паузу, скушать Твикс(R)©. И посмотреть как у других получится, на какие грабли наступят. Это как минимум полгода.
Не факт, если к примеру через два месяца исчезнут в канале HP DL380G4p (хотя, судя по запасам на складах Интел....), то хочешь не хочешь а возмешь HP DL380G5. Да и разница по перформансу между G4p и G5 уж очень большая — я б наверно долго не ждал...

Если у вас парк настольных компьютеров измеряется тысячами, то зоопарк здесь неуместен. Должна быть 100% гарантия работоспособности корпоративного софта (это не шутка)
Плавали, знаем (с)
Не один год проработал в компаниях где в головном офисе более 1000ПК
Как-то было обнаружено что на P4 при вкл. НТ один софт от собственных разработчиков вис, хотя на ТС с 2-я Зеон с вкл. НТ работал без глюков
Но более всего зоопарк неуместен в плане несовместимости HAL, правда еще ни разу не слышал чтобы руководство гд-то это осознавало.
Часто выбирают какого-то поставщика корпоративным, а что он внутрь поставит бог его знает, привозят партию из 5ПК, а там три разных модели мамок (модель чипсета, видео, сеть, .... ) — первоначально времени на инсталляцию в таких случаях уходит неприлично много, да и впоследствии на сотню разных конфигураций готовых снимков с диска не напасешься... Может поэтому я и сторонник терминальных клиентов :gigi:

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


matik
При росте числа точек подключения шина все сильнее отстает по скорости и задержкам от коммутатора. Коммутатор — гораздо более разумное техническое решение.
Так и более накладное по сложности, разводке, площади, энергопотреблению...
При большом числе узлов общая шина конечно нафиг никому не нужна, но вот при числе узлов до 4 эта кольцевая шина может быть даже очень и очень

Бррр.... Это будет совсем ужас. При росте числа точек подключения шина все сильнее отстает по скорости и задержкам от коммутатора. Коммутатор — гораздо более разумное техническое решение.
Не спорю прост Интел что-то такое говорил о некой кольцевой шине в будущих процессорах мультиядерных процессорах. На хоботе заметка была кажется :) Дело в том что преполагается, как бы делать процессоры(кристаллы) не из отдельно ядер кеша итп а как бы из маленьких самостоятельных процессоров каждый из которых имеет свой кеш и все они типа будут соеденены кольцевой шиной, даже назвали это гомогенной архитектурой что ли . Вобщем пока это научная фантастика...:D
matik

Бррр.... Это будет совсем ужас. При росте числа точек подключения шина все сильнее отстает по скорости и задержкам от коммутатора. Коммутатор — гораздо более разумное техническое решение. 

Тут, понимаешь, ли, есть точка перегиба. До определенного момента (определяемого протоколами доступа и пропускной способностью) шинное решение обеспечивает меньшую латентность и больший КПД (при маркерном доступе), чем коммутируемое решение. Плюс, такая система имеет фиксированную латентность, что приятно для реалтайм систем (вывод видео — как раз требует четкой синхронизации процессов).

Ну, и, разумеется, такая архитектура не в пример экономичнее по части транзисторов. Так что для системы с 4-8 абонентами и протоколом типа "TokenRing" (что особенно удобно ввиду предсказуемости нагрузки) — шинная (кольцевая маркерная) топология очень даже хороша.


Последний раз редактировалось Stranger_NN 12:34 27.07.2006, всего редактировалось 1 раз.
Warrax
При большом числе узлов общая шина конечно нафиг никому не нужна, но вот при числе узлов до 4 эта кольцевая шина может быть даже очень и очень
Ыыыыыы!!!!!
Ну попробуй ответить на вопрос: ладно, шина, все понятно. ЗАЧЕМ КОЛЬЦЕВАЯ?! Ну что за бред? :D
Stranger_NN
До определенного момента (определяемого протоколами доступа и пропускной способностью) шинное решение обеспечивает меньшую латентность и больший КПД (при маркерном доступе), чем коммутируемое решение
Ээээ...
Ровно наоборот. Предсказуемая задержка как раз у коммутатора. На шине бывают ведь еще и коллизии, чего в коммутаторе в принципе не бывает. Не, я за коммутатор.
matik, а затем и кольцевая, что маркерный (или последовательный) доступ, а не CSMA/CD. Причем, разумеется, это может быть логическое кольцо, а не физическое (хотя двунаправленное физическое кольцо — тоже вполне правильно).


Ровно наоборот. Предсказуемая задержка как раз у коммутатора. На шине бывают ведь еще и коллизии, чего в коммутаторе в принципе не бывает. Не, я за коммутатор. 

Разумеется, на шине с коллизиями — задержки непредсказуемы, а на маркерной(последовательного доступа) — коллизий нет и быть не может по определению. Оттого и задержки там фиксированные. И меньшие, чем у коммутаторов — обработка проще.

Во время оно, передача видеотрафика по 4mbps TR происходила на-амного ровнее, чем по 10mbps Ethernet. А при количестве машин от 10-12 — совокупная ПСП у TR оказывалась больше (фактически, при любой нагрузке все 4mbps и было, а у Ethernet деградировало до уровня ~3,5mbps совокупных, иногда и еще меньше..)
Stranger_NN
Во время оно, передача видеотрафика по 4mbps TR происходила на-амного ровнее, чем по 10mbps Ethernet.
Но виноват в этом был явно не коммутатор, правда? :)

а затем и кольцевая, что маркерный (или последовательный) доступ, а не CSMA/CD. Причем, разумеется, это может быть логическое кольцо, а не физическое (хотя двунаправленное физическое кольцо — тоже вполне правильно).
Тогда (если существует строгая очередность доступа) результирующая задержка будет выше, чем у коммутатора. По одной простой причине: невозможны одновременные передачи двух пакетов. Тогда как коммутатор с неблокирующейся матрицей может коммутировать все порты друг с другом одновременно.

Как ни крути, результат один: либо одному порту на шине достается в среднем меньше, чем на коммутаторе, либо возможен "захват" шины.
Warrax
А вот с быстрым ремонтом А-Бренда по гарантии на наших просторах вообще никак

Именно поэтому был выбран поставщик "ноунэйм". Было два принципиальных требования — всегда есть стандартная рассыпуха на 50-80 машин и замена по списку (не обмен ;)) по приезду водителя. К счастью, после смены поставщика они согласились ЗИП выкупить. Минимальные изменения конфигурации, например, замена дисков (разумеется одного производителя и одной линейки) на более емкие или процессора на более высокочастотные по причине потенциального обнуления запасов на складе и полного отсутсвия на рынке старых моделей обговаривались заранее и принимались с огромным скрипом.

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

Так что для меня, если честно, поставка в течении 2 лет одной и той же конфигурации выглядит как нечто из области ненаучной фантастики
Фантастика была в другом. Когда я впервые познакомился с представителями этой компании, я был "несколько удивлен" наполеоновскими планами развития. Правильная, жесткая политика в области ИТ, привнесенная западными менеджерами, лишь часть общей политики развития. Самое удивительное, что этим наполеоновским планам было суждено сбыться...
matik

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

А почему ты решил, что в кольце только один маркер? :oops: Это ниоткуда не следует. :-p Были и мультимаркерные сети.

Тогда как коммутатор с неблокирующейся матрицей может коммутировать все порты друг с другом одновременно.

Да, разумеется. Но при этом он вносит существенную задержку, состоит из большого количества вентилей и имеет очень сложную разводку. Сам прикинь коммутатор хотя бы на 10 шин, ну, пускай HT2... и опять же, конкуренции за порт назначения для коммутирующей матрицы никто не отменял, чего на маркерном кольце быть не может в принципе.

Как ни крути, результат один: либо одному порту на шине достается в среднем меньше, чем на коммутаторе, либо возможен "захват" шины.

Захват при маркерном доступе невозможен, конкуренция за порт назначения — тоже невозможна. Единственный минус — невозможность одномоментной связи различный пар, но так ли это надо, если разобраться? :spy:
Stranger_NN
Были и мультимаркерные сети.
А вот они уже гораздо сложнее по арбитражу, правда? :)

Да, разумеется. Но при этом он вносит существенную задержку, состоит из большого количества вентилей и имеет очень сложную разводку. Сам прикинь коммутатор хотя бы на 10 шин, ну, пускай HT2... и опять же, конкуренции за порт назначения для коммутирующей матрицы никто не отменял, чего на маркерном кольце быть не может в принципе.
Стоп :)
1. "Существенная задержка" для коммутирующей матрицы, работающей на частоте процессора — единицы наносекунд (!). Согласен?
2. Состоит из большого количестве вентилей — да, согласен. Зато и результат хорош.
3. Сложная разводка — зависит от количества портов. Для 10 портов ничего архисложного не вижу. А больше нам вряд ли понадобится в ближайшем будущем.
4. Конкуренция за порт назначения откуда может взяться? От того, что к некоторым устройствам (например, к контроллеру памяти) будут обращаться чаще других. Правильно? Для кольцевой шины будет то же самое, контроллер памяти будет самым востребованным портом.

Единственный минус — невозможность одномоментной связи различный пар, но так ли это надо, если разобраться?
А ты себе представь четыре ядра. Ты хочешь, чтобы три ждало, пока четвертое общается с контроллером памяти? Дык это будут те самые грабли, на которые наступил Интел со своей шинной архитектурой четырехпроцессорных систем.
Только теперь эти грабли будут внутри одного кристалла, только и всего.

Неее, комплект "шины точка-точка + коммутатор" мне гораздо больше нравится.
matik

А вот они уже гораздо сложнее по арбитражу, правда?

Разумеется, неправда! :-p С чего бы?

1. "Существенная задержка" для коммутирующей матрицы, работающей на частоте процессора — единицы наносекунд (!). Согласен?
2. Состоит из большого количестве вентилей — да, согласен. Зато и результат хорош.
3. Сложная разводка — зависит от количества портов. Для 10 портов ничего архисложного не вижу. А больше нам вряд ли понадобится в ближайшем будущем.
4. Конкуренция за порт назначения откуда может взяться? От того, что к некоторым устройствам (например, к контроллеру памяти) будут обращаться чаще других. Правильно? Для кольцевой шины будет то же самое, контроллер памяти будет самым востребованным портом.

1. Согласен. Теперь умножь на количество пакетов... Набегает...
2. В чем он хорош? :spy: В множественных перекрестных связях? А зачем они тебе?
3. Сравни двойное кольцо и 10 дуплексных линков. У меня в 10 раз больше проводов, а у тебя? :-p
4. Востребованным-то он будет, но конкуренции не будет. Потому что если пришел маркер — то адресат заведомо готов принять пакет. А вот коммутатору придется эти пакеты либо где-то буферизовать, либо дропать и инициировать повтор передачи. :oops:

А ты себе представь четыре ядра. Ты хочешь, чтобы три ждало, пока четвертое общается с контроллером памяти? Дык это будут те самые грабли, на которые наступил Интел со своей шинной архитектурой четырехпроцессорных систем.

Вот именно, что нет!! Пришел пустой маркер — передавай данные. Шина не деградирует под нагрузкой, как у Интел, когда, даже при заведомо достаточной ПС FSB увеличение процессоров не приводило к линейному росту производительности. Кстати, в такой топологии число контроллеров памяти может быть больше одного. :shuffle:

Неее, комплект "шины точка-точка + коммутатор" мне гораздо больше нравится.

Мне тоже, если не пытаться затолкать его на кристалл, где и так тесно. :oops:
Stranger_NN
Согласен. Теперь умножь на количество пакетов... Набегает..
Зачем умножать?! :eek: Что за цифра получится? Задержка на переключение матрицы всегда одинаковая...

В чем он хорош? В множественных перекрестных связях? А зачем они тебе?
Хорош он в том, что одно ядро может обмениваться данными с контроллером НТ, второе — с контроллером памяти, и все это НЕЗАВИСИМО друг от друга. На шине ОДНОВРЕМЕННО это НЕВОЗМОЖНО. Физически.

Сравни двойное кольцо и 10 дуплексных линков. У меня в 10 раз больше проводов, а у тебя?
Разводка у коммутатора сложнее, здесь спору нет. Но характеристики — лучше. Собственно, вопрос уже давно решился в пользу коммутаторов :) Где Token Ring, а где коммутаторы? :)

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

Вот именно, что нет!! Пришел пустой маркер — передавай данные. Шина не деградирует под нагрузкой, как у Интел, когда, даже при заведомо достаточной ПС FSB увеличение процессоров не приводило к линейному росту производительности. Кстати, в такой топологии число контроллеров памяти может быть больше одного
Илья, стой :) У тебя есть шина с некоей пропускной способностью. Чем больше у тебя на ней устройств, тем меньше достается каждому. Правильно, или нет? :)
В коммутаторе у каждого устройства ПОЛНАЯ скорость соединения.

Мне тоже, если не пытаться затолкать его на кристалл, где и так тесно.
А вот это пущай технологи думают :)
matik

Зачем умножать?! Что за цифра получится? Задержка на переключение матрицы всегда одинаковая...

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

Хорош он в том, что одно ядро может обмениваться данными с контроллером НТ, второе — с контроллером памяти, и все это НЕЗАВИСИМО друг от друга. На шине ОДНОВРЕМЕННО это НЕВОЗМОЖНО. Физически.

Да, это так. Но гораздо проще сделать двойное кольцо с избыточной ПС, чем вводить в схему коммутатор с требуемыми ТТХ..

Собственно, вопрос уже давно решился в пользу коммутаторов Где Token Ring, а где коммутаторы?

Это, скорее, вопрос к IBM, запатентовавшей технологию и устанавливавшей совершенно несуразные цены на оборудование.

Я говорю о коммутаторе внутри процессора, у которого все порты работают на одинаковой (высокой) скорости. Здесь нет нужды в буферизации, и так далее.

Есть, и никуда тебе не деваться! Вот у тебя два ядра кидают что-то в адрес контроллера памяти. Разумеется, что принять его порт может одновременно только один пакет, следовательно, второй нужно где-то буферизовать и поставить в очередь. Причем, с ростом количества ядер — вероятность конкуренции за порт назначения будет только возрастать, что потребует увеличения объемов буферной памяти.

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

Илья, стой У тебя есть шина с некоей пропускной способностью. Чем больше у тебя на ней устройств, тем меньше достается каждому. Правильно, или нет? В коммутаторе у каждого устройства ПОЛНАЯ скорость соединения.

Стою. :D Совершенно правильно ты говоришь, но только для случая равномерной нагрузки. В случае же неравномерной нагрузки — доступная ПС будет определяться пропускной способностью самого нагруженного звена, деленного на число обратившихся. Я тебе заранее скажу, что узким местом будет контроллер памяти.

Так вот, в кольцевой двунаправленной системе (маркерной, или с последовательным опросом) средняя латентность будет меньше из-за отсутствия промежуточной буферизации. А дефицит ПС гораздо проще скомпенсировать увеличением "ширины" шины. :-p

А вот это пущай технологи думают

А зачем, если это не приведет к росту производительности? :spy:
Stranger_NN
Что-то мы о разном :D

Еще разок, медленно.
Допустим, есть у тебя некая шина (сейчас неважно, кольцевая она, или восьмерками). С пропускной способностью 20 байт за такт (цифра условна).
Если у тебя есть два ядра и контроллер памяти, каждому из ядер достанется в среднем 10 байт. Если у тебя четыре ядра и контроллер — в среднем каждому ядру достанется 5 байт. При этом контроллер памяти и там, и там может принять\отдать максимум 20 байт.
У тебя производительность ограничена СВЕРХУ, пропускной способностью шины.

Теперь посмотрим, что в случае коммутатора.
У тебя есть два ядра, контроллер памяти, и контроллер НТ. Допустим, контроллер памяти дает\берет те же 20 байт за такт. Теперь одно ядро можно соединить с контроллером памяти, а второе — ОДНОВРЕМЕННО С ЭТИМ соединить с контроллером НТ.
При этом ОБА будут заняты делом, на ПОЛНОЙ скорости.
Имеем ДВА независимых НЕБЛОКИРУЮЩИХСЯ соединения.
С контроллером памяти ОБА этих варианта равносильны по пропускной способности: больше, чем пропустит контроллер памяти, нам не получить.
Но общий КПД системы во втором случае выше, потому что позволяет занять ДРУГИЕ порты полезной работой.

Общий итог: второй вариант технически совершенней.
Intel демостративно воротит нос:
[Intel pulls ATI from Conroe launch]

Сташная вещь — гордыня... :(
Хе-хе :D
Core2 6800 XE принадлежит к FMB 05B, то есть TDP до 130Вт :D
Странно, почему процессор с формальным TDP 75Вт не отнесли к FMB 05A? Ведь те — до 95Вт? :D
matik
Не, как ни крути, ну не вижу я преимущств. В свое время АТИ много и долго говорила о том, какой это "прорыв", но что-то сильно я в этом сомневаюсь.
Странно ... А зачем АТИ прибегнула к такому подходу, если преимуществ нет?
Чисто из эстетических соображений? :D И решили нанять модного дизайнера из Италии? ;)

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

matik
Если у тебя есть два ядра и контроллер памяти, каждому из ядер достанется в среднем 10 байт. Если у тебя четыре ядра и контроллер — в среднем каждому ядру достанется 5 байт. При этом контроллер памяти и там, и там может принять\отдать максимум 20 байт.
Подождите, вы полагаете в К8Л будет такой же контроллер 1/2х64 как у текущих К8?
matik
Странно, почему процессор с формальным TDP 75Вт не отнесли к FMB 05A? Ведь те — до 95Вт?
Кстати, 6800 ХЕ вроде как бы и под TDP 95W проходит, если судить по иному доку :gigi:
U2
Подождите, вы полагаете в К8Л будет такой же контроллер 1/2х64 как у текущих К8
Нет, число 20 байт абсолютно условное. Я ничего не имел в виду :D

Кстати, 6800 ХЕ вроде как бы и под TDP 95W проходит, если судить по иному доку
Голубчики, видимо, "еще не определились" :D
matik
Голубчики, видимо, "еще не определились"
если ничего не помогает, прочтите, наконец, документацию ©
BorisU
если ничего не помогает, прочтите, наконец, документацию
А Вы — маркировку процессора :D Благо, фотки в инете доступны ;)
matik
И что вам с этой маркировки?
О, что в имени моём... ©

Там 05В.
Ну и что?
BorisU
см. выше
и что? там нормируется куча параметров системы питания проца, если по каким-то оно не прошло — поставили FMB 05B. ПРоцессор же не стал от такой маркировки жрать больше? :no:
matik

The thermal profile for Intel Pentium D 775_VR_CONFIG_05A processors (TDP = 95 W) and the 775_VR_CONFIG_05B Intel® Core™2 Duo Extreme Processor X6800 (TDP = 95 W) is also defined such that a single thermal solution (e.g., RCBFH-3 or BTX TMA Type II reference designs) would be compliant.


The table also includes the ambient assumption, TA, for the Intel reference thermal solution at the processor fan heatsink inlet as discussed in Section 3.3. An external ambient temperature to the chassis of 35 °C is assumed, resulting in a temperature rise, TR, of 4 °C for solutions supporting 775_VR_CONFIG_05B processors. Meeting TA and ΨCA targets can maximize processor performance (refer to Sections 2.2, 2.4, and Chapter 4). By minimizing TR, in the performance chassis this helps lead to improved acoustics

Table 3. ATX Heatsink Performance Targets
Processor                                                   Target Thermal     TA
                                                           Performance, Ψca    Assumption
                                                              (Mean + 3σ)
Intel Pentium D 900 processors and Intel                       0.23 °C/W       TA = 39 °C
Pentium processor Extreme Edition 955 and 965
775_VR_CONFIG_05B processors (130 W TDP)

Intel Core™2 Duo Extreme processor X6800                       0.27 °C/W       TA = 40 °C
775_VR_CONFIG_05B processors (95 W TDP)

Intel Pentium D processor 800 sequence                         0.25 °C/W       TA = 40 °C
775_VR_CONFIG_05A processors (95 W TDP)

в даташите на conroe написано 75 :)
BorisU
в даташите на conroe написано 75
Ну наконец-то! :D

Вот я и удивляюсь, так сколько же там на самом деле? :D В одном месте написано одно, в другом — другое. А NAWHI интересный эффект обнаружил :)
matik
Вот я и удивляюсь, так сколько же там на самом деле?
Прямые измерения fcenter вас не устраивают?
matik
В одном месте написано одно, в другом — другое. А NAWHI интересный эффект обнаружил
Что за эффект?
BorisU
Прямые измерения fcenter вас не устраивают?
Их я тоже принял к сведению. Но я не отбрасываю факты только потому, что они мне не нравятся ;)

U2
Что за эффект?
Охлаждая X6800 боксовым кулером от Prescott-а, NAWHI обнаружил на Core 2 Duo Extreme X6800 тротлинг...
По этому поводу BorisU там гневно "нефанатствовал" :D
matik
Гнать не надо.
Тестили не финальный степпинг.
BorisU
Гнать не надо
Не надо, согласен :D
Однако в моих сообщениях гона нет :D Стало быть, ....?


Тестили не финальный степпинг
Как дежурное объяснение, это вполне может быть принято к сведению. Но отрицать факт мы ведь не будем, правда? :D
не знаю, была ли эта ссылка или нет, но мне было интересно 8-)
matik
Однако в моих сообщениях гона нет
Это вам кажется. флажочек поищите :yes:

Но отрицать факт мы ведь не будем, правда?
Как можно отрицать, если статья все еще висит :)

Но мы также не будем отрицать, что никто из других тестеров перегрева не обнаружил, правда? И те кто мерили температуру, ничего близкого к 80 градусам, при которых якобы был троттлинг, тоже не намеряли.


Последний раз редактировалось BorisU 00:38 28.07.2006, всего редактировалось 1 раз.
BorisU
Это вам кажется
Боюсь, что это ВАМ кажется, что он там есть :) Все (!) свои высказывания я могу подтвердить ссылками (хотя и лениво несколько).
А флажочек, увы, более не Ваш.

Но мы также не будем отрицать, что никто из других тестеров перегрева не обнаружил, правда?
И не думаем отрицать. Правда, это очень слабый аргумент. Видите ли, я слишком хорошо знаю, что определенные вещи обнаруживают только некоторые тестеры :D
BorisU
И те кто мерили температуру, ничего близкого к 80 градусам, при которых якобы был троттлинг, тоже не намеряли.
Остается задать один ОЧЕНЬ ПРОСТОЙ вопрос: скажите, а КАК они измеряли температуру? :D Вы это знаете?
matik
А флажочек, увы, более не Ваш.
А я и не претендовал, просто жалко что такую раритетную вещь потеряли :)

Все (!) свои высказывания я могу подтвердить ссылками
тоже мне фокус. я тоже могу
matik
Остается задать один ОЧЕНЬ ПРОСТОЙ вопрос: скажите, а КАК они измеряли температуру? Вы это знаете?
не интересовался. Но полагаю, что мониторингом встроеным :) Ровно так же как и ixbt.
Новая тема    Ответить  [ Сообщений: 4488 ]  На страницу Пред.  1 ... 77, 78, 79, 80, 81, 82, 83 ... 113  След.


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 12


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  

Удалить cookies конференции

Пишите нам | Radeon.ru