POSIX (và Linux nói chung) không bao giờ thực sự có bộ hẹn giờ được đảm bảo theo nghĩa nếu bạn đặt thứ gì đó ở chế độ ngủ, bạn có thể mong đợi nó thức dậy vào một thời điểm chính xác nhất định. Bạn chỉ có thể đảm bảo rằng việc đánh thức diễn ra SAU thời điểm đã nêu, không chính xác vào thời điểm đó và chẳng bao giờ trước nó*.
Linux không phải là thời gian thực và thực sự chỉ cố gắng hết sức.
Từ người đàn ông 2 nanosleep tuân thủ POSIX:
nanosleep() tạm dừng việc thực thi chuỗi cuộc gọi cho đến khi một trong hai
ít nhất thời gian được chỉ định trong *req đã trôi qua hoặc việc gửi một
tín hiệu kích hoạt lời gọi của trình xử lý trong luồng gọi
hoặc kết thúc quá trình.
Nếu bạn đang mong đợi các dấu tích đáng tin cậy, thì vấn đề có nhiều khả năng là bạn không có kinh nghiệm để quản lý một trang trình bày bên trong một cửa sổ nhất định.
Đề xuất của tôi ở đây là hãy suy nghĩ lại về thiết kế ứng dụng của bạn để kém tin cậy hơn khi đánh thức chính xác hoặc có một dự phòng an toàn trong trường hợp có sự chậm trễ không mong muốn.
I E
- Phần mềm bị hủy bỏ do một số bất thường về độ trễ.
- Phần mềm khi đánh thức nhận thấy sự khác biệt so với một số nguồn thời gian có thẩm quyền khác và 'bước' ý tưởng về lần đánh thức tiếp theo để bù lại.
- Bạn in một cảnh báo hoặc cung cấp một số thông báo khác.
Thật không hợp lý khi nghĩ rằng thời gian là đáng tin cậy trong một hệ thống có thể áp dụng trước. Ngay cả trên kim loại trần.
- Non-Maskable Interrupts không thể bị chặn.
- Tải cao có nghĩa là bạn vừa lên lịch trong một thời gian dài.
- Việc gián đoạn CPU được gọi bởi phần cứng có thể gây ra sự chậm trễ.
- Các lỗi trang nhỏ và lớn có thể tạo ra độ trễ rất lâu giữa các lần đánh thức hẹn giờ.
- Phân bổ bộ nhớ trên các ngân hàng bộ nhớ không thuộc sở hữu của CPU thêm độ trễ.
Đây thực sự chỉ là một chức năng của điện toán x86 hiện đại.
Ít nhất là trên KVM, có một nguồn đồng hồ được gọi là 'kvm-clock', được cho là đại diện cho các tích tắc từ trình ảo hóa cơ bản bất kể có bất kỳ độ trễ không xác định nào trong VM. Bạn có thể tìm thấy tệp đó và những gì bạn đã đặt trong đường dẫn này: /sys/devices/system/clocksource/clocksource*/current_clocksource và xem những lựa chọn của bạn là gì /sys/devices/system/clocksource/clocksource*/available_clocksource.
Nhưng một lần nữa, máy chủ bên dưới có thể có độ trễ riêng. Vì vậy, nó chỉ là con rùa đi xuống..
Đừng dựa vào đảm bảo thời gian thực không tồn tại. Xây dựng phần mềm để đối phó với sự chậm trễ không mong muốn hoặc ít nhất là biết về chúng.
NTP nói chung là toàn bộ giao thức nhằm xử lý vấn đề về thời gian, thời gian nào là 'chính xác' và phải làm gì để xử lý các thay đổi về thời gian. Đó là một vấn đề khá phức tạp.
Cách tốt nhất là bạn muốn thiết lập hệ thống để làm cho vấn đề khó xảy ra theo thống kê, hãy nghĩ xem điều gì (nếu có) sẽ tạo thành cơ quan đáng tin cậy về thời gian trong ứng dụng của bạn và sau đó là cách bạn muốn xử lý các sự kiện không chắc xảy ra khi thời gian thay đổi .
Có thể bạn thiết lập một số SLA nói rằng thời gian sẽ không chính xác khi kiểm tra 1000000 mẫu. Điều đó -- có thể xảy ra, mặc dù không chắc về mặt thống kê là bọ ve đã tắt.
Cách tôi xem xét thời gian khi làm việc với các nhóm có hệ thống khác nhau mà tất cả đều có liên quan với nhau, đó là điều quan trọng hơn là vị trí thời gian của chúng* nằm trong một cửa sổ khác biệt nhỏ. Ở mức độ đó, tôi sẽ có một thiết lập máy chủ thời gian cục bộ sử dụng một số nguồn có thẩm quyền, sau đó tất cả các máy tính trong nhóm đó sẽ đồng bộ hóa với hệ thống cục bộ đó. Máy chủ thời gian cục bộ có độ trễ rất thấp giúp giảm rung pha cục bộ và tất cả các máy chủ sẽ được đồng bộ hóa rất chặt chẽ.
Một số triển khai hẹn giờ sử dụng bộ xử lý tín hiệu để bẫy các sự kiện. IE SIGALRM, nếu bạn gửi một quy trình tín hiệu ALRM bên ngoài bộ hẹn giờ, nó sẽ thức dậy trước nó.
Địa phương ở đây sẽ là tất cả các máy tính có liên quan logic với nhau, tất cả đều nằm trong khoảng thời gian có lẽ là vài mili giây với nhau. Nhưng chúng có thể khác nhau rất nhiều giữa các địa phương khác, IE là một nhóm các hệ thống có độ trễ cách xa 500 mili giây.
