Здравствуйте, Sinclair, Вы писали:

S>Конечно, мои знания ограничены.

Они у всех ограничены. Все знать нельзя — не DOS времена.

>Но тебе же незнание основ устройства дотнета не помешало критиковать его?

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

S>У меня нет под рукой Соломона-Руссиновича.

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


S>Возможно, я что-то неверно понимаю. Но ты не мог бы мне пояснить, как именно Working Set процесса влияет на остальные процессы? Вот у меня типичное количество свободной физической памяти ~ 500 mb. Это означает, что отожранные янусом мегабайты никому не жмут. Я также заметил, что янус отжирает не фиксированное количество памяти. Когда у меня было 525 метров — он тратил 30 метров. Сейчас — 112.

Ничего удивительного

if(lowMemory)
VirtualAlloc (еще)
else
// как-нибудь обойдемся тем, что есть

И если в коде Януса такого явно и нет, то это не значит, что такого нет в .Net Framework или в исполняющей системе.


>Process Explorer при этом показывает 94.6 MB Private Bytes. Он же показывает 45 мегабайт во всех хипах дотнета. (Это все три поколения + Large Objects Heap). При этом Reserved = 92 Mb. То есть на всякий случай дотнет держит полсотни метров памяти про запас. Что-то мне подсказывает, что эти байты можно при нужде легко отдать.
S>Вот я сминимайзил януса — и его working set стал 1.5 Мb. Примерно за полсекунды. То есть когда у меня таки кончатся эти 500 метров свободной памяти (что означает, что я запустил какой-то еще фотошоп), янус подвинется и отдаст.

Попробую объяснить.

Private Bytes — это не так интересно. Равно как и Commited Bytes (включает в себя еще и не-private). Это объем вирт. памяти, который процесс коммитировал. Грубо говоря, это объем тех адресов, по которым можно обращаться без того, чтобы схлопотать AV.

Мне ничего не стоит сделать Commited Bytes (в Task Manager называется VM Size) для своей програмы большим, чем размер RAM. При этом часть будет выделена в RAM, часть в файлах (свопе, MMF)

А вот Working Set — это совсем другое дело. Это те страницы, которые сейчас в RAM. Это то, что твоя программа сейчас забрала себе.

Все процессы начинают работу с фиксированного Working Set (значений под руками нет). Далее они могут запрашивать все больше и больше памяти, VM Size будет у них расти (только они сами могут его потом уменьшить, освободив память) а вот будет ли при этом увеличиваться
Working Set — зависит от ситуации в машине. Если памяти RAM свободной много, то будет. Более того, система может даже дать больше, чем максимум (см. SetProcessWorkingSetSize). Если же памяти мало, то система будет вытеснять страницы, а не давать новые.

Теперь о минимизации. Разумеется, система отдает предпочтение активному приложению. И вот его минимизировали. Поскольку ты явно заявил, что не будешь с ним работать сейчас (правда это или нет — другой вопрос), то система усекает его Working Set , отнимая у него страницы.

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

Так чот уменьшить Working Set можно мгновенно практически — просто объявить эти страницы более не принадлежащими процессу, и все. Никакой записи на диск при этом вообще не произойдет.

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

Теперь сам можешь понять, что происходит. Минимизировали приложение. Уменьшился резко Working Set. А дальше что будет — зависит от a) много ли RAM и b) насколько агрессивно новый процесс (с которым теперь начали работать) запрашивает память и как давно с ним не работали.

Если RAM много, а преемник не агрессивный, то отложенную запись будут откладывать . Некуда спешить — в системе тихо и мирно, всем памяти хватает.
Но если RAM мало, или преемник агрессивный, или с ним просто давно не работали (а для давно минимизированных процессов ОС может довести его Working Set до нуля), то начинается вот что. Преемник хочет памяти (или явно сейчас запрашивает, или, если с ним давно не работали, то он сейчас вернулся и просит вернуть ему Working Set . Срабатывает событие "количество свободных страниц станет меньше некоторого минимума". Начинается запись модифицированных страниц. Одновременно идет чтение страниц преемника (а куда денешься!). В итоге тормоза.

У меня на машине этот эффект проявляется, к примеру на Mozilla. Она у меня запущена всегда и я с ней почти не работаю, могу час-два к ней не обращаться. Если запустить некий процесс, активно отъедающий память, а потом переключиться на Мозиллу — тормоза очень заметны.

Так что чудес не бывает. Суммируя, могу сказать- если процесс захватил 60 Мб Working Set и эти данные не R/O, то их записывать на диск будут (разве что процесс убьют, тогда, мб, и не будут). Но, конечно, не немедленно, а когда потребуется. И если таких процессов много (а минимизация, как сам понимаешь, отнюдь не гарантирует, что процесс не будет ничего делать, это лишь в большинстве случаев так), то свопинг будет хороший. Но размазанный по времени, так что ощутит юзер тормоза или нет — от многих факторов зависит.

Поэтому , кстати, ASP.NET пользуется большой популярностью, а WinForms — нет. Для ASP.NET процесс-то, по существу, один — aspnet_wp.exe. Даже если там пять сайтов крутится и пользователей из Интернета тысяча. А вот если все приложения на рабочей станции перевести на .Net — будет тихий ужас. Если простенький пример Влада ухитрился иметь 60 Мб Working Set (хоть убей, не понимаю, как такого можно добиться! Если бы от меня потребовали такое на Win32 написать — отказался бы, не знаю, как это можно сделать — то при десятке таких приложений будет примерно то, как работа Windows 95 на 4 Мб. Не пробовал ? MS тогда заявила, что будет работать (3.1 прекрасно работала). Я и попробовал




PD>>Антон, честное слово — почитай. Тебе самому стыдно будет читать, что ты здесь написал.
PD>>Вообще меня удивляет в тебе одно. Ты прекрасно разбираешься во многом. Но зачем ты делаешь заявления в том, в чем ты явно не разбираешься — это я понять не могу.
S>Я не делаю заявлений. Я не понимаю, почему начинаются сказки про прожорливость приложений, которую так трудно заметить. Я не вполе понимаю все это многообразие цифр, которые показывают различные перформанс тулы. Я вижу, что весь этот Working Set — это фикция, поскольку легким манием руки он прыгает с 400 до 2, а потом до 30М.

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

И последнее. ИМХО у тебя сложилось впечатление, что я противник .Net. Вовсе нет. В целом я ее существование только приветствую, и отдаю ей должное. Хорошая система. Но не надо ее возможности преувеличивать. Поэтому я смотрю на вещи трезво. В чем-то она хороша, в чем-то нет. В чем-то классический С++ прекрасен, где-то его лучше и не пытаться применять. А вот для вас, похоже, нет бога, кроме .Net и бог един, посему остальным — анафема и костер!

Ну и коль уж о боге речь зашла, закончу фразой из писания

Не сотвори себе кумира

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Я вот одно не пойму в ваших с Владом рассуждениях. С точки зрения пользователя ПК все эти внутренние дела .Net, для изучения которых годится профайлер — интереса не представляет. Есть объем рабочего множества, он у Влада был 60 Мб на 10000 строках в гриде. Зачем он такой нужен — меня как пользователя не касается, а вот захватить 60 Мб под грид с 10000 записями — это суметь надо! Лично я за решение такой задачи на Win API, пожалуй , не возьмусь — фантазии не хватит, на что 60 Мб употребить

Какой ты пользовтель? Нормальный пользователь работает, а не байты считает. Ты скорее скряга сохнущая над перерасходом 10 мег из гигабайта.

А тот самы обычный пользователь нихрена не заметит. Вот, например, в SQL Server 2000 была утилита "Query Analyzer". Дерьмова, неудобная, но написанная на C++ и соотвественно жрушая мег 20-30 на моей машине. В SQL Server 2005 ее заменила отличная IDE на основе VS 2005 и того самого "прожорливого" грида. Работать стало удобно. Возможностей стало больше. Памяти жрется под 100 метров в некоторых случаях, но блин, что мне до того? 10 студий мне открывать и не хочется (хотя это и не проблема).

PD>А страницы эти, между прочим, скорее всего модифицированными помечены. Так что при их вытеснении (при минимизации) им в своп-файл идти придется. Даже если их оттуда обратно брать не будут...

Психолог. Однозначно требуется психолог...

Здравствуйте, Pavel Dvorkin, Вы писали:

VD>>ВыньФормс-приложение с DataGridView
VD>>заполненным 10 000 строк (с одной колонкой)
VD>>после изнурительного скролинга по всем
VD>>строкам 60 496 61 032

PD>Win32 приложение с 10 000 строк после
PD>изнурительного скроллинга по всем строкам 2 816 1 008

Я тебе уже сказал. Поставь на машину 64 метра и опрадуйся от того, что и дотнетное приложние заняло 2-3 метра.

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


VD>>В общем, кончайте эту охоту на ведьм. Если у вас психологические проблемы с восприятием объемов памяти

PD>Без всяких психологических проблем 10 приложений по 60 Мб скушают всю память,

Вы батенька мошенничаете. Сравниваете совсем разные вещи и делаете далеко идущие выводы. Я кажется привел характеристики пустого приложения и приложения с ListView.
К тому же я довольно внятно продемонстрировал, что реально занимается виртуалка. И что если другим процессам/потокам требуется физическая память, то она немедленно возвращается в систему.

PD> даже если некоторые из них будут минимизироваться (что еще не означает, что они не будут работать, между прочим).

Минимизация сбрасывает ворксет. После востановления окна ворксет становится таким каким он действительно нужен приложению (по минимому). А до этого ЖЦ занимает столько памяти, сколько считает разумным. Запустив приложение на машине с 20 гигами можно получить и пару сотен мег. А запустив на 64 просто пару.

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

PD>Хороший способ полемики, ничего не скажешь!

Это не способ. Это факт. У тебя чисто психологические проблемы. Жадность проще говоря. Жалеишь цифирьки.

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

PD>А в чем, собственно, тут оптимизация произошла, можно узнать ?

В том, что сборка мусора не ведется до тех пор пока это действительно не потребуется.

PD>Win32 приложение так же великолепно показывает и скроллирует листбокс, как и .Net приложение.

Ты сам выбрал задачу где скорость не то что не критична, но и вообще мало интересна. ЖЦ еще не столь умен, чтобы определять где нужно оптимизировать скорость, а где объем занятой памяти.

Что же до скорости, то на 64 метрах под NT4 память дотнетным приложением будет так же заниматься куда меньше, а скорость по прежнему будет уператься в видиокарту и алгоритмы отрисовки.

Здравствуйте, _Artem_, Вы писали:

_A_>Мы бы хотели добавить еще памяти, да ктож нам ее даст, а на свои деньги покупать жаба давит . А на 256 или хуже того 128 это будут жутко тормозить

А кто тебе сказал, что этот самый грид будет тормозить на 128 метрах? Ты пробовал?

Ну, да опять таки... если требования экономить память не фига использовтаь гриды написанные в 2005-ом году в рассчете на новую технику. Пользуйся тем же ListView. Хотя реально это конечно фобии.

Ну, а тормоза у тебя скорее появятся не от нехватки памяти, а от передачи 10 000 записей по сети.

Здравствуйте, <Аноним>, Вы писали:

А>Да уж, замечательно.
А>Признать что на некоторых машиных, с малым объемом памяти будут тормоза мы не можем.

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

Причем реальные траты памяти не так уж и велики. Ведь занимается неиспользуемамя память. Если вдруг память нужна системе она отадется. Да и тормоза — это слишком громко сказано. Работа ЖЦ конечно шустрее если есть большой запас по памяти, но до тех пор пока ОС не села на своп проблем особо заметно не будет. Да скорость будет ниже. Да при переключении между задачами будет задержка размеров в 0.3-1 секунду. Но фактически пользователь

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

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Ничего удивительного

PD>if(lowMemory)
PD> VirtualAlloc (еще)
PD>else
PD>// как-нибудь обойдемся тем, что есть

PD>И если в коде Януса такого явно и нет, то это не значит, что такого нет в .Net Framework или в исполняющей системе.

ты хочешь сказать что оно моментально скидывает в своп?

Здравствуйте, Pavel Dvorkin, Вы писали:

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

Давай посмотрим с другой стороны и не будем закапываться в кишки ОС — .NET приложения буквально моментально отдают память, которую они заняли? да, и это мы видим на практике. Хотя на самом деле тут ничего даже исключающего из правил нет — они действительно сжирают эту память. Но как сжирают — это вопрос.

Вот например жизненная ситуация — послали тебя в командировку, поселили тебя одного в пятиместный номер. Что ты делаешь? правильно, распологаешься на "широкую руку" — все свои вещи по всему номеру, пиво поближе к себе, носки поставишь в дальний угол Тебе так удобно? да. Но это не значит что ты уже не сможешь существовать в более маленьком пространстве. Завтра приедут остальные 4 твоих товарища — и ты в течении 5 минут всё свое барахло стягиваешь к своей койке, ну носки возможно прийдется даже постирать Тебе удобно так? конечно, одному было вольготнее, но и в таких условиях можно вполне сносно существовать. А не приехали бы сослуживцы — может, ты бы носки так бы в угол и ставил бы и на стирку времени не потратил. Да, есть тут момент — вещи нужно к себе сгребать в случае резкого появления сожителей. Ну такова специфика. А зато если бы не приехали — ты бы более "эффективно" жил бы, нежели если бы сразу занял только свой уголок.
Так и .NET . Вообще-то ему нужно чтобы было много памяти на машине — чтобы было где развернуться, а потом можно потихоньку уменьшать свое жизненное пространство...

Здравствуйте, VladD2, Вы писали:

VD>А тот самы обычный пользователь нихрена не заметит. Вот, например, в SQL Server 2000 была утилита "Query Analyzer". Дерьмова, неудобная, но написанная на C++ и соотвественно жрушая мег 20-30 на моей машине. В SQL Server 2005 ее заменила отличная IDE на основе VS 2005 и того самого "прожорливого" грида. Работать стало удобно. Возможностей стало больше. Памяти жрется под 100 метров в некоторых случаях, но блин, что мне до того? 10 студий мне открывать и не хочется (хотя это и не проблема).
А вот мне нравится Query Analyzer, тем более что от него много и не требуется выполение запросов и построение их планов плюс просмотр информации по таблицам ...
А 100 мб. памяти отожрать это же как постараться нужно, может они там в Microsoft сговорились с разработчиками памяти и отжирают ее специально

Здравствуйте, parapet, Вы писали:


P>ты хочешь сказать что оно моментально скидывает в своп?

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

Здравствуйте, parapet, Вы писали:

P>Здравствуйте, Pavel Dvorkin, Вы писали:

<все аналогии skipped>

P>есть такая крылатая фраза — горе от ума Чем глубже мы погружаемся в какую-либо область и чем более ясны логические цепочки — тем тяжелее нам представить что-либо, что не вписывается в наши логические выводы в этой области. Об этом нужно всегда помнить — такова специфика нашего мозга — обладая глубокими знаниями о чем-либо — наш мозг отбрасывает все, что идет вразрез с этими знаниями Птицы тоже не должны летать, т.к. они тяжелее воздуха. И в теорию относительности я не верю (уж больно какая-то она сухая), несмотря на то, что логически она очень даже выстроена

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

P>Давай посмотрим с другой стороны и не будем закапываться в кишки ОС — .NET приложения буквально моментально отдают память, которую они заняли? да, и это мы видим на практике. Хотя на самом деле тут ничего даже исключающего из правил нет — они действительно сжирают эту память. Но как сжирают — это вопрос.

Нет. Это не вопрос. Дело в том, что пока не появится ОС, в которой .Net в ядре, до тех пор программы .Net есть просто процессы Windows. И в этом плане они ничем не отличаются от других процессов. И об их поведении надо судить по тем средствам, которые Windows предоставляет для изучения поведения процессов. Вот и все. Как они там внутри устроены — это их внутреннее дело. Чистые Win API приложения — так-то, приложения .Net — иначе, приложения FoxPro — еще как-то и т.д. Свою систему напишешь — еще что-то будет. А с точки зрения ОС это все процессы, 3 кольцо.

Здравствуйте, VladD2, Вы писали:


VD>Психолог. Однозначно требуется психолог...

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

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Однозначно требуется специалист, способный отучить тебя от хамства. Боюсь только, что это никому не под силу.

Удивительное дело: как между собой общаются — так нормальные люди, а как с Вами — так сразу почему-то хамят. . Просто напасть какая-то

Здравствуйте, VGn, Вы писали:

VGn>Удивительное дело: как между собой общаются — так нормальные люди, а как с Вами — так сразу почему-то хамят. . Просто напасть какая-то

Ты не прав. Павел не первый и не единственный, кто обратил внимание на манеру общения VladD2.

Здравствуйте, VladD2, Вы писали:

VD>А тот самы обычный пользователь нихрена не заметит. Вот, например, в SQL Server 2000 была утилита "Query Analyzer". Дерьмова, неудобная, но написанная на C++ и соотвественно жрушая мег 20-30 на моей машине.

Зря ты так. Ее очень не хватает в 2005-ом.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Можно еще не верить в то, что земля круглая — жизненный опыт человека, никогда не покидавшего своего города, этому явно противоречит.

а может и не круглая. А если и круглая — то для некоторых задач мы вполне можем ее рассматривать как плоскую. И результаты будут достаточно точны.

P>>Давай посмотрим с другой стороны и не будем закапываться в кишки ОС — .NET приложения буквально моментально отдают память, которую они заняли? да, и это мы видим на практике. Хотя на самом деле тут ничего даже исключающего из правил нет — они действительно сжирают эту память. Но как сжирают — это вопрос.

PD>Нет. Это не вопрос. Дело в том, что пока не появится ОС, в которой .Net в ядре, до тех пор программы .Net есть просто процессы Windows. И в этом плане они ничем не отличаются от других процессов. И об их поведении надо судить по тем средствам, которые Windows предоставляет для изучения поведения процессов. Вот и все. Как они там внутри устроены — это их внутреннее дело. Чистые Win API приложения — так-то, приложения .Net — иначе, приложения FoxPro — еще как-то и т.д. Свою систему напишешь — еще что-то будет. А с точки зрения ОС это все процессы, 3 кольцо.

ну есть немножко издержки по притеснению процессов, есть. Но как ни крути нельзя сказать про программу на .НЕТ что она сожрала 60 метров памяти. Вот если сишная сожрала — так это сожрала, ты хоть убейся не отдаст она 50 метров за короткое время. Так что тут заявлять что .НЕТ программа сожрала в прямом смысле слова 50 метров — ну это слишком громко сказано...

Здравствуйте, parapet, Вы писали:

P>Здравствуйте, Pavel Dvorkin, Вы писали:

<skipped>

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

Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, VGn, Вы писали:

VGn>>Удивительное дело: как между собой общаются — так нормальные люди, а как с Вами — так сразу почему-то хамят. . Просто напасть какая-то

L>Ты не прав. Павел не первый и не единственный, кто обратил внимание на манеру общения VladD2.

Просто Влад когда идет в крестовый поход бывает рубит не глядя...

Здравствуйте, parapet, Вы писали:

P>ну есть немножко издержки по притеснению процессов, есть. Но как ни крути нельзя сказать про программу на .НЕТ что она сожрала 60 метров памяти. Вот если сишная сожрала — так это сожрала, ты хоть убейся не отдаст она 50 метров за короткое время. Так что тут заявлять что .НЕТ программа сожрала в прямом смысле слова 50 метров — ну это слишком громко сказано...

Иными словами, ты хочешь сказать, что одно и то же значение WorkingSetSize в блоке EPROCESS в ядре для процесса означает разные вещи в зависимости от того, на каком языке писался исходный код ?

Запретить тебе так считать никто не может. Равно как и верить, что Земля плоская. Но все же советую прочитать серьезную литературу, потому что это утверждение звучит анекдотически.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Иными словами, ты хочешь сказать, что одно и то же значение WorkingSetSize в блоке EPROCESS в ядре для процесса означает разные вещи в зависимости от того, на каком языке писался исходный код ?

Мне кажется вы зря иронизируете.
Вопрос не в языке, а в том, что в .NET есть GC, который умеет эффективно реагировать на просьбы подвинуться.
Собственно именно это вам сказали уже много раз.

Здравствуйте, parapet, Вы писали:

P>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Можно еще не верить в то, что земля круглая — жизненный опыт человека, никогда не покидавшего своего города, этому явно противоречит.

P>а может и не круглая. А если и круглая — то для некоторых задач мы вполне можем ее рассматривать как плоскую. И результаты будут достаточно точны.

Люди, вас обманули! Земля вовсе не круглая! Круглым может быть только что-то двумерное. Широко известно, что Земля имеет форму Земли. Так и называется: "геоид".
Существует огромное количество задач, для которых и шарообразная форма, и эллипсоидальная — слишком неточные приближения.