LINUX.ORG.RU
Форум — Development  

Flush QSerialPort QFile

 , , ,


0

1

Заметил странную вещь связанную flush:

В QSerialPort отправляю в порт 5Мб, вызываю flush и сразу же получаю подтверждение записи, хотя осциллографом видно что данные еще выходят. С waitForBytesWritten тоже самое.

В QFile flush тоже не дает желаемого результата, сбросил на флешку 1000Мб записалось со скоростью 100Мб/сек, как я понял это скорость чтения с винта в оперативку, так как реальная скорость записи на устройство 2МБ/сек. Flush прошел, тут же вызвал fsync(file.handle()) и как и ожидал завис до окончания реальной записи...

Вопросы:

1. Как в QSerialPort получить подтвержение реального окончания записи в порт? fsync не работает с сокетом (не удивлен).

2. Как добиться баланса между скоростью копирования и контролем процесса. Не очень весело залить все в оперативку и не иметь возможности слежения за процессом копирования, а хотелось бы иметь возможность отмены копирования при необходимости.

← Инициализация памяти оператором new в c++
QSqlDatabase: QMYSQL driver not loaded →

flush неблокирующий, потому он сразу и выходит.

waitForBytesWritten имеет аргумент таймаут. Попробуй с -1 вызывать

a1batross ★★★★★
()
Ответ на: комментарий от a1batross

Таймаут в 30 сек сразу вылетает.

flush неблокирующий

зачем он нужен? Что он делает просто генератор константы true?

Попробуй с -1 вызывать

пробовал тоже самое

LinuxDebian ★★★★
() автор топика
Последнее исправление: LinuxDebian (всего исправлений: 1)

Отправлять не сразу всё. Кусочками. После отправки кусочка спать нужное время в зависимости от требуемой оптимальной скорости передачи данных. И, я не ковырял сериал порты, там что, совсем нет возможности получить инфу ушли ли данные?

deep-purple ★★★★★
()
Ответ на: комментарий от deep-purple

Отправлять не сразу всё. Кусочками.

С портом еще ладно. А с файлом? Я заморчился проводить бенчмар на лету скорости чтения и записи, исходя из него менял размер фрагмента, скорость получается где-то почти в двое ниже возможной. Это печалено.

там что, совсем нет возможности получить инфу ушли ли данные

знал бы - не спрашивал...

LinuxDebian ★★★★
() автор топика
Последнее исправление: LinuxDebian (всего исправлений: 1)
Ответ на: комментарий от LinuxDebian

А с файлом?

Так же. Или понимая что это файл слать не кусочками а сразу всё.

знал бы - не спрашивал

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

deep-purple ★★★★★
()
Ответ на: комментарий от deep-purple

Так же. Или понимая что это файл слать не кусочками а сразу всё.

Так в этом то и проблема, чем больше кусков тем ниже скорость... Чем меньше кусков тем хуже отзывчивость при отмене, хуже отображение прогресса и скорости...

Нет, я имел ввиду ушли ли данные в порт с точки зрения отправителя

Я именно так и понял. Говорю же не могу найти как это узнать, флуш не работает, данные ушли в драйвер и я получил от него «ок» походу...

Наслышан, обратной связи от получателя через сериал порт нет

Именно так, и так и должно быть.

LinuxDebian ★★★★
() автор топика
Последнее исправление: LinuxDebian (всего исправлений: 2)
Ответ на: комментарий от x905

скорости обмена + немного запаса

Как сделать через Ж... я знаю, я ищу способ через «апи».

Пиши по 1Мб, на hdd скорость не просядет, ssd будет не хуже hdd

Я делаю такое на лету, не на всех железяках оно нормально работает.

LinuxDebian ★★★★
() автор топика
Ответ на: комментарий от LinuxDebian

Как сделать через Ж… я знаю, я ищу способ через «апи».

отсутствие в протоколе обмена подтверждений - это и есть через Ж…

Я делаю такое на лету, не на всех железяках оно нормально работает.

тест dd не нормально работает на этих железяках ?

x905 ★★★★★
()
Ответ на: комментарий от x905

отсутствие в протоколе обмена подтверждений - это и есть через Ж…

Звучит как молоток ж..., отвертка лучше. С вами батенька нечем говорить.

тест dd не нормально работает на этих железяках ?

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

LinuxDebian ★★★★
() автор топика
Последнее исправление: LinuxDebian (всего исправлений: 2)
Ответ на: комментарий от LinuxDebian

Звучит как молоток ж…, отвертка лучше.

ага, звучит именно так, что ты стал молотком шурупы забивать

разная скорость при одном и том же размере блока

если на блоке в 1Мб она максимальна на всех дисках - то это и есть решение покажи тест, где это не так

x905 ★★★★★
()
Ответ на: комментарий от x905

ага, звучит именно так, что ты стал молотком шурупы забивать

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

покажи тест, где это не так

покажу когда пойму почему. Еще раз перепроверю.

LinuxDebian ★★★★
() автор топика
Последнее исправление: LinuxDebian (всего исправлений: 2)
Ответ на: комментарий от LinuxDebian

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

есть определенная разница, но какая цель достигается тут знанием о реальном уходе данных ?

ведь если пакет и отправлен, например в сеть, то удаленный пользователь может его и не получить никогда

x905 ★★★★★
()
Ответ на: комментарий от x905

Чтобы не переполнился буфер отправки за пределами юзерспейса. Таким образом можно было бы сделать более «дешевый» контроль скорости передачи данных. На случай если данные для отправки будут появляться чаще чем возможно их отправить, станет понятно, что «источник» «неисправен»...

LinuxDebian ★★★★
() автор топика
Последнее исправление: LinuxDebian (всего исправлений: 3)
Ответ на: комментарий от x905

буфера QSerialPort на передачу

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

LinuxDebian ★★★★
() автор топика
Последнее исправление: LinuxDebian (всего исправлений: 3)
Ответ на: комментарий от x905

Тест это хорошо, но это не кросплатформенно, не универсально, тесть для частного случая (для текущего ядра итд...). Легче контролировать поток данных до отправки в порт. Хочется средств ОС для «надежной работы»

LinuxDebian ★★★★
() автор топика
Последнее исправление: LinuxDebian (всего исправлений: 1)

У драйвера есть буфер, этот буфер может принимать данные и говорить тебе что отправлено. А потом еще долго отправлять

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

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

говорить тебе что отправлено. А потом еще долго отправлять

плохо, что же придется с портом смирится и сделать все ручками.

LinuxDebian ★★★★
() автор топика
Ответ на: комментарий от LinuxDebian

«терминал (получатель, пользователь-диспетчер)» - это уникальная железяка или самописный софт ?

скорость потока данных отправителя больше скорости передачи ?

x905 ★★★★★
()
Ответ на: комментарий от x905

Скорость генератора может быть выше скорости отправки «сборщика» и чтобы до диспетчера дошло хоть что-то нужно контролировать поток. Все самописное просто припадок перфекционизма у меня...

LinuxDebian ★★★★
() автор топика
Последнее исправление: LinuxDebian (всего исправлений: 1)
Ответ на: комментарий от I-Love-Microsoft

Ну естественно. У него виш, и протокол свой. Вот пусть доработает и синкует в обе стороны.

deep-purple ★★★★★
()
Ответ на: комментарий от LinuxDebian

Все самописное просто припадок перфекционизма у меня…

если передающему не важно, принял ли получатель данные, то можно и не подтверждать прием, например логи работы

иначе нужен протокол с квитированием

x905 ★★★★★
()
Ответ на: комментарий от LinuxDebian

Таймаут в 30 сек сразу вылетает.

Хм, странно, должно ждать.

Попробуй tcdrain() на QSerialPort::handle() после того как сделал flush().

kuzulis ★★
()
Ответ на: комментарий от LinuxDebian

зачем он нужен? Что он делает просто генератор константы true?

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

А вообще, читай доку: https://doc.qt.io/qt-5/qserialport.html#flush

kuzulis ★★
()
Ответ на: комментарий от deep-purple

там что, совсем нет возможности получить инфу ушли ли данные?

В общем случае - нет.

kuzulis ★★
()
Ответ на: комментарий от x905

я не уверен в размере буфера QSerialPort на передачу,

Ограничен размером ОЗУ :)

kuzulis ★★
()
Ответ на: комментарий от LinuxDebian

зачем он нужен? Инициирует начало записи сейчас (если это возможно). Если его не вызывать сброс буфера в устройство контролируется системой.

anonymous
()
Ответ на: комментарий от kuzulis

Согласен ступил, можно ли узнать «статус» дескриптора, сколько там данных ядро еще не записало?

tcdrain

тоже пролетает в момент.

LinuxDebian ★★★★
() автор топика
Ответ на: комментарий от LinuxDebian

можно ли узнать «статус» дескриптора, сколько там данных ядро еще не записало

В принципе есть флаг TIOCOUTQ (см. http://man7.org/linux/man-pages/man4/tty_ioctl.4.html). Но оно может быть не реализовано в драйвере вообще, или возвращать пустышку.

тоже пролетает в момент.

странный какой-то сериал порт у тебя.

kuzulis ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Инициализация памяти оператором new в c++
Development
QSqlDatabase: QMYSQL driver not loaded →