Trong kỹ thuật truyền thông, độ trễ hiếm khi do một thiết bị duy nhất gây ra. Nó bị tiêu hao dần từng chút: trong mạng truy cập, chuyển mạch, định tuyến, lập lịch không dây, mã hóa, đệm, chuyển đổi giao thức, xử lý máy chủ, hàng đợi ứng dụng và thậm chí cả giải mã tại điểm cuối.
Ngân sách độ trễ truyền thông mang lại cho những mili giây đó một nơi thuộc về. Nó xác định mỗi phần của hệ thống được phép tiêu hao bao nhiêu độ trễ trước khi trải nghiệm tổng thể trở nên không thể chấp nhận.
Ngân sách độ trễ truyền thông là gì?
Ngân sách độ trễ truyền thông là sự phân bổ có kế hoạch độ trễ chấp nhận được trên toàn bộ đường truyền thông. Thay vì chỉ nói "hệ thống phải có độ trễ thấp", các kỹ sư chia tổng độ trễ cho phép thành các phần nhỏ hơn. Mỗi đoạn mạng, mô-đun xử lý, liên kết truyền dẫn, thiết bị đầu cuối, nền tảng hoặc lớp ứng dụng nhận được mục tiêu độ trễ riêng.
Xác định khoảng dịch vụ đo lường trước khi phân bổ mili giây: miệng-tai một chiều, báo động-đến-đầu ra, thiết lập cuộc gọi hoặc khứ hồi yêu cầu là những đại lượng khác nhau. Ghi lại điểm quan sát, hướng và độ không đảm bảo thời gian. Không giả định độ trễ một chiều bằng một nửa RTT khi đường dẫn hoặc xử lý không đối xứng.
Nguyên tắc tương tự áp dụng cho hội nghị truyền hình, điều khiển công nghiệp, giám sát từ xa, liên lạc điều phối, truy cập đám mây, hệ thống tự hành và cộng tác thời gian thực. Ngân sách độ trễ trở thành tài liệu tham chiếu thiết kế cho biết đội dự án nơi nào độ trễ có thể chấp nhận, nơi nào phải giảm thiểu và nơi nào được phép đánh đổi.
Điều này làm cho việc lập ngân sách độ trễ khác với kiểm thử hiệu năng thông thường. Kiểm thử đo lường những gì đã xảy ra. Lập ngân sách độ trễ định hình hệ thống trước khi triển khai. Nó giúp các kỹ sư tránh phát hiện quá muộn rằng kiến trúc không thể đáp ứng thời gian phản hồi yêu cầu.
Tại sao tổng độ trễ cần được chia nhỏ
Chỉ nhìn vào tổng độ trễ có ích cho nghiệm thu cuối cùng, nhưng không đủ cho thiết kế. Nếu hệ thống vượt mục tiêu, đội phải biết phần nào tiêu hao quá nhiều thời gian. Vấn đề do truy cập không dây, định tuyến WAN, xử lý codec, hàng đợi ứng dụng, máy chủ quá tải hay đệm quá mức? Không có ngân sách độ trễ, khắc phục sự cố trở thành phỏng đoán.
Chia nhỏ độ trễ tạo ra khả năng hiển thị. Mỗi đội có thể hiểu trách nhiệm của mình. Đội mạng quản lý độ trễ truyền tải và hành vi hàng đợi. Đội ứng dụng kiểm soát xử lý và phản hồi cơ sở dữ liệu. Đội thiết bị đầu cuối giảm thời gian mã hóa và giải mã. Đội vận hành giám sát tắc nghẽn và thay đổi định tuyến. Chủ dự án sau đó có thể đánh giá liệu toàn bộ hệ thống vẫn trong giới hạn đã hoạch định.
Việc phân chia này cũng ngăn chặn kỳ vọng không thực tế. Khách hàng có thể yêu cầu độ trễ cực thấp trong khi cũng yêu cầu xử lý đám mây đường dài, video độ nét cao, mã hóa nặng, truy cập không dây và tích hợp nhiều nền tảng. Ngân sách độ trễ làm cho sự đánh đổi trở nên rõ ràng. Nó cho thấy thời gian đang bị tiêu hao ở đâu và liệu yêu cầu có thể đạt được với kiến trúc đã chọn hay không.
Trong các dự án thực tế, ngân sách độ trễ rõ ràng giúp tránh các tranh luận mơ hồ. Thay vì nói "mạng chậm" hoặc "ứng dụng nặng", các đội có thể so sánh độ trễ đo được với độ trễ hoạch định cho từng phần. Điều này biến thảo luận hiệu năng thành phân tích kỹ thuật.
Lợi ích chính trong thiết kế dự án
Lợi ích đầu tiên là khả năng dự đoán. Hệ thống truyền thông thời gian thực không thể chỉ dựa vào hiệu năng trung bình. Chúng cần phản hồi ổn định trong điều kiện bận rộn. Ngân sách độ trễ cung cấp mục tiêu cho đội thiết kế trước khi chọn thiết bị, định cỡ liên kết, đặt máy chủ hoặc chọn giao thức. Điều này giảm nguy cơ xây dựng hệ thống hoạt động trong phòng thử nghiệm nhưng thất bại trong vận hành thực tế.
Lợi ích thứ hai là lựa chọn kiến trúc tốt hơn. Nếu ngân sách độ trễ nghiêm ngặt, một số lựa chọn thiết kế có thể không phù hợp. Máy chủ đám mây từ xa có thể thêm quá nhiều thời gian khứ hồi. Liên kết không dây có thể cần xử lý biên cục bộ. Luồng video có thể cần codec khác hoặc đệm thấp hơn. Hệ thống điều khiển có thể cần khả năng sống sót cục bộ thay vì gửi mọi lệnh qua nền tảng từ xa.
Lợi ích thứ ba là hoạch định dung lượng rõ ràng hơn. Độ trễ tăng khi hàng đợi tích tụ. Nếu băng thông, CPU, bộ nhớ, lưu trữ hoặc tài nguyên vô tuyến không đủ, gói tin và tác vụ chờ lâu hơn. Ngân sách độ trễ buộc các kỹ sư xem xét không chỉ liệu dữ liệu có thể đi qua, mà liệu nó có thể đi qua trong thời gian yêu cầu.
Lợi ích thứ tư là kiểm thử nghiệm thu dễ dàng hơn. Khi dự án đã xác định mục tiêu độ trễ cho từng phần, nghiệm thu không giới hạn ở một lần kiểm thử end-to-end. Các kỹ sư có thể xác minh độ trễ thiết bị đầu cuối, mạng, máy chủ và ứng dụng riêng biệt. Điều này làm cho kết quả cuối cùng đáng tin cậy hơn và dễ bảo trì hơn.
Độ trễ thường bị tiêu hao ở đâu
Độ trễ truyền thông thường ẩn trong những nơi nhỏ. Truyền dẫn vật lý thêm độ trễ lan truyền, đặc biệt trên khoảng cách dài. Chuyển mạch và định tuyến thêm độ trễ chuyển tiếp. Tắc nghẽn tạo ra độ trễ hàng đợi. Tường lửa, VPN, thiết bị mã hóa và cổng giao thức thêm độ trễ kiểm tra hoặc chuyển đổi. Hệ thống không dây thêm lập lịch, truyền lại và thời gian phục hồi tín hiệu.
Thiết bị đầu cuối cũng đóng góp vào ngân sách. Micro, camera, cảm biến, điện thoại, intercom, bộ điều khiển hoặc thiết bị di động có thể cần thời gian để thu, mã hóa, nén, mã hóa bảo mật, đóng gói, giải mã và phát dữ liệu. Trong hệ thống thoại, bộ đệm jitter thường cần thiết để làm phẳng biến động đến của gói tin, nhưng bộ đệm lớn hơn làm tăng độ trễ. Trong hệ thống video, độ phức tạp mã hóa có thể tạo ra độ trễ nhìn thấy được ngay cả khi mạng khỏe mạnh.
Nền tảng ứng dụng thêm một lớp khác. Một yêu cầu có thể chờ trong hàng đợi ứng dụng, đi qua cổng API, truy vấn cơ sở dữ liệu, kích hoạt message broker, gọi dịch vụ khác hoặc chờ xác thực. Các bước này có thể bình thường, nhưng chúng vẫn tiêu hao thời gian. Trong hệ thống dựa trên đám mây, mỗi hop dịch vụ bổ sung có thể ảnh hưởng đến ngân sách độ trễ tổng.
Đây là lý do lập ngân sách độ trễ nên bao gồm toàn bộ đường dịch vụ, không chỉ mạng. LAN nhanh không thể bù đắp cho logic ứng dụng chậm. Máy chủ mạnh không thể loại bỏ độ trễ do truyền tải đường dài. Thiết kế tốt nhìn vào toàn bộ chuỗi.
Ngân sách độ trễ truyền thông được sử dụng ở đâu?
Lĩnh vực áp dụng: thoại và liên lạc điều phối
Liên lạc thoại là một trong những lĩnh vực trực tiếp nhất cho lập ngân sách độ trễ. Hội thoại của con người nhạy cảm với độ trễ vì mọi người mong đợi việc luân phiên nói ngay lập tức. Khi độ trễ một chiều trở nên quá cao, người nói ngắt lời nhau, nhịp điệu hội thoại trở nên không tự nhiên và các chỉ thị lệnh cảm thấy chậm. Điều này đặc biệt quan trọng trong điều phối, phòng điều khiển, khẩn cấp và liên lạc an toàn công cộng.
Trong hệ thống thoại, ngân sách độ trễ có thể bao gồm xử lý âm thanh tại điểm cuối, độ trễ codec, khoảng gói, chuyển tiếp mạng, bộ đệm jitter, định tuyến máy chủ, chèn ghi âm và chuyển đổi cổng. Nếu cuộc gọi thoại đi qua nhiều nền tảng hoặc mạng công cộng, ngân sách độ trễ càng trở nên quan trọng.
Liên lạc điều phối có kỳ vọng vận hành nghiêm ngặt hơn so với gọi điện văn phòng thông thường. Người vận hành có thể cần đưa ra chỉ thị nhanh chóng, ngắt liên lạc thường lệ, kết nối nhóm hoặc phối hợp ứng phó khẩn cấp. Nếu độ trễ hệ thống quá cao, quá trình chỉ huy cảm thấy mất kết nối với tình hình thực địa.
Ngân sách độ trễ giúp người lập kế hoạch quyết định liệu xử lý thoại nên cục bộ, liệu đường WAN có thể chấp nhận, liệu chuyển đổi cổng nên được giảm thiểu và liệu có cần xử lý ưu tiên cho gói thoại hay không. Nó cũng giúp giải thích tại sao sử dụng băng thông thấp không tự động có nghĩa là độ trễ thấp. Lưu lượng thoại có thể nhẹ, nhưng nó vẫn cần thời gian có thể dự đoán được.
Để lập kế hoạch dự án, hãy xem xét cổng vô tuyến BK-ROIP4 cùng với bảng điều khiển điều phối; xác minh giao diện, cấu hình và bằng chứng chấp nhận cho dịch vụ dự định.
Lĩnh vực áp dụng: hội nghị truyền hình và giám sát trực tiếp
Hệ thống video thường có hành vi độ trễ phức tạp hơn hệ thống thoại. Đường video bao gồm thu hình từ camera, xử lý hình ảnh, mã hóa, truyền tải mạng, đệm, giải mã, hiển thị và đôi khi trộn hoặc ghi hình trên đám mây. Video độ nét cao, giảm nhiễu, nén và kiểm soát bitrate thích ứng đều có thể thêm độ trễ.
Đối với hội nghị truyền hình, độ trễ thấp rất quan trọng vì người dùng tương tác theo thời gian thực. Nếu độ trễ quá cao, thảo luận trở nên gượng gạo và ngắt lời tăng lên. Đối với giám sát trực tiếp, độ trễ chấp nhận được phụ thuộc vào trường hợp sử dụng. Tổng quan an ninh có thể chấp nhận nhiều độ trễ hơn so với vận hành từ xa, chỉ huy khẩn cấp hoặc kiểm tra công nghiệp trực tiếp.
Ngân sách độ trễ truyền thông giúp các kỹ sư quyết định nơi xử lý video nên diễn ra. Một số hệ thống có thể xử lý video tập trung. Những hệ thống khác cần xử lý biên để tránh gửi mọi luồng đến nền tảng từ xa. Nếu video được sử dụng để xác nhận an toàn hoặc điều khiển từ xa, ngân sách phải nghiêm ngặt hơn so với ghi hình thông thường.
Video cũng cạnh tranh băng thông. Khi mạng bị tắc nghẽn, bộ đệm video có thể tăng và độ trễ có thể tăng. Do đó, QoS, bộ nhớ đệm cục bộ, lựa chọn luồng và kiểm soát bitrate nên được xem xét như một phần của ngân sách độ trễ thay vì thêm vào sau khi vấn đề xuất hiện.
Lĩnh vực áp dụng: điều khiển công nghiệp và tự động hóa
Truyền thông công nghiệp thường sử dụng ngân sách độ trễ vì các hành động điều khiển có thể phụ thuộc vào thời gian có thể dự đoán. Đọc cảm biến, chỉ thị bộ điều khiển, tín hiệu báo động hoặc cập nhật trạng thái máy có thể không dùng nhiều băng thông, nhưng có thể cần đến trong thời gian xác định. Trong những trường hợp này, độ trễ không chỉ là vấn đề trải nghiệm người dùng; nó có thể ảnh hưởng đến độ ổn định của quy trình và an toàn.
Các ứng dụng công nghiệp khác nhau có yêu cầu thời gian khác nhau. Bảng điều khiển giám sát có thể chấp nhận độ trễ vài giây. Hệ thống phối hợp sản xuất có thể cần phản hồi dưới một giây. Hệ thống điều khiển chuyển động hoặc bảo vệ có thể yêu cầu thời gian nghiêm ngặt hơn nhiều và có thể không phù hợp với mạng chia sẻ thông thường. Ngân sách độ trễ giúp tách biệt các yêu cầu này thay vì đối xử với tất cả dữ liệu công nghiệp như nhau.
Đối với các dự án tự động hóa, lập ngân sách độ trễ hỗ trợ quyết định về bộ điều khiển cục bộ, cổng biên, mạng riêng, chuyển đổi giao thức và kết nối đám mây. Nếu vòng điều khiển không thể chấp nhận độ trễ WAN, nó nên ở lại cục bộ. Nếu phân tích đám mây hữu ích nhưng không quan trọng về thời gian, chúng có thể hoạt động ngoài đường điều khiển nghiêm ngặt.
Việc tách biệt này rất thực tế. Nó cho phép các tổ chức hiện đại hóa hệ thống công nghiệp mà không buộc mọi tín hiệu vào kiến trúc từ xa. Các hành động thời gian thực vẫn gần thiết bị, trong khi dữ liệu không thời gian thực có thể được gửi đến nền tảng cấp cao hơn.
Lĩnh vực áp dụng: không dây, 5G và mạng biên
Truyền thông không dây làm cho việc lập ngân sách độ trễ quan trọng hơn vì điều kiện vô tuyến thay đổi. Cường độ tín hiệu, nhiễu, chuyển giao, lập lịch, truyền lại và mật độ người dùng đều có thể ảnh hưởng đến độ trễ. Liên kết có dây có thể hoạt động dễ dự đoán hơn, trong khi hệ thống không dây cần hoạch định cẩn thận hơn cho các dịch vụ thời gian thực.
Trong mạng không dây riêng, 5G, Wi-Fi và mạng di động, ngân sách độ trễ giúp quyết định liệu ứng dụng có thể chạy qua lớp vô tuyến và vẫn đáp ứng mục tiêu hay không. Ví dụ: push-to-talk, kiểm tra video, điều phối di động, điều khiển AGV và bảo trì từ xa có thể có mức độ chấp nhận khác nhau. Một thiết kế không dây không thể tự động đáp ứng mọi trường hợp.
Điện toán biên thường được giới thiệu để giảm độ trễ. Thay vì gửi tất cả dữ liệu đến đám mây từ xa, xử lý có thể được đặt gần người dùng, máy móc, camera hoặc thiết bị hiện trường hơn. Điều này giảm độ trễ truyền tải và cũng có thể giảm tắc nghẽn trên mạng backhaul.
Ngân sách độ trễ giúp chứng minh nơi các nút biên nên được đặt. Nếu ngân sách cho thấy truyền tải đường dài tiêu hao quá nhiều thời gian, xử lý cục bộ trở nên cần thiết. Nếu yêu cầu độ trễ lỏng lẻo, xử lý tập trung vẫn có thể chấp nhận được. Điều này giữ triển khai biên gắn với nhu cầu hiệu năng thực tế thay vì kiến trúc theo xu hướng.
Lĩnh vực áp dụng: dịch vụ đám mây và ứng dụng phân tán
Dịch vụ đám mây và ứng dụng phân tán thường chứa nhiều điểm độ trễ ẩn. Yêu cầu của người dùng có thể đi qua DNS, mạng truy cập, tường lửa, bộ cân bằng tải, cổng API, dịch vụ xác thực, máy chủ ứng dụng, cơ sở dữ liệu, bộ nhớ đệm, hàng đợi tin nhắn và giao diện bên thứ ba. Mỗi bước có thể chấp nhận được riêng lẻ, nhưng tổng thời gian phản hồi có thể trở nên quá cao.
Ngân sách độ trễ giúp các kiến trúc sư đám mây quyết định mỗi lớp được phép tiêu hao bao nhiêu thời gian. Nếu phản hồi cơ sở dữ liệu chậm, lớp ứng dụng không nên che giấu vấn đề bằng cách thử lại quá mức. Nếu cổng API thêm chi phí kiểm tra, nó nên được đưa vào ngân sách. Nếu dịch vụ bên thứ ba không thể dự đoán, ứng dụng có thể cần kiểm soát timeout hoặc xử lý bất đồng bộ.
Đối với ứng dụng phân tán, ngân sách cũng giúp quyết định nơi dữ liệu nên được đặt. Một dịch vụ thường xuyên đọc dữ liệu từ vùng xa có thể bị độ trễ không cần thiết. Bản sao khu vực, bộ nhớ đệm cục bộ, mạng phân phối nội dung và dịch vụ biên có thể giảm độ trễ khi được sử dụng đúng cách.
Đây là lý do lập ngân sách độ trễ không giới hạn ở kỹ thuật viễn thông. Nó cũng hữu ích trong kiến trúc phần mềm, di chuyển đám mây, nền tảng SaaS, hệ thống tài chính, dịch vụ trực tuyến và nền tảng kỹ thuật số doanh nghiệp nơi thời gian phản hồi ảnh hưởng đến trải nghiệm người dùng và hiệu quả kinh doanh.
Lĩnh vực áp dụng: hệ thống khẩn cấp và liên quan đến an toàn
Hệ thống khẩn cấp phải được thiết kế có tính đến độ trễ vì liên lạc muộn có thể làm giảm hiệu quả ứng phó. Kích hoạt báo động, gọi khẩn cấp, phát thanh công cộng, chỉ thị điều phối, xác nhận video và thông báo cho người ứng cứu không nên phụ thuộc vào chuỗi xử lý không thể dự đoán. Ngân sách độ trễ giúp xác định mỗi hành động phải diễn ra nhanh đến mức nào.
Ví dụ: cuộc gọi khẩn cấp có thể cần đến phòng điều khiển nhanh chóng. Báo động hoảng loạn có thể cần hiển thị thông tin vị trí mà không chờ nhiều dịch vụ từ xa. Thông báo công cộng có thể cần bắt đầu trong thời gian ngắn sau khi người vận hành xác nhận. Nguồn video có thể cần mở đủ nhanh để hỗ trợ xác minh hiện trường.
Độ trễ chấp nhận được phụ thuộc vào kịch bản. Thông báo bảo trì có thể chấp nhận nhiều độ trễ hơn chỉ thị sơ tán. Bản ghi sự kiện chung có thể ít khẩn cấp hơn kênh thoại trực tiếp. Ngân sách độ trễ giúp phân loại các hành động này để hệ thống bảo vệ các đường dẫn nhạy cảm về thời gian nhất.
Trong hệ thống liên quan đến an toàn, lập ngân sách độ trễ cũng hỗ trợ kiểm thử. Đội dự án có thể kiểm tra liệu thời gian từ báo động đến hiển thị, thời gian thiết lập cuộc gọi, thời gian bắt đầu thông báo hoặc thời gian mở video có đáp ứng yêu cầu vận hành hay không. Điều này làm cho nghiệm thu thực tế hơn là chỉ kiểm tra xem mỗi hệ thống con có được kết nối hay không.
Cách tạo ngân sách độ trễ thực tế
Ngân sách độ trễ thực tế bắt đầu từ yêu cầu dịch vụ, không phải từ danh sách thiết bị. Các kỹ sư trước tiên nên xác định loại liên lạc nào đang được hỗ trợ và tổng độ trễ chấp nhận được là bao nhiêu. Thoại, video, điều khiển, giám sát, báo cáo và truyền tệp không nên chia sẻ một mục tiêu chung.
Bước tiếp theo là lập bản đồ toàn bộ đường dẫn. Điều này bao gồm điểm cuối, mạng truy cập, chuyển mạch, định tuyến, WAN, liên kết không dây, thiết bị bảo mật, cổng, máy chủ, cơ sở dữ liệu, ứng dụng và thiết bị hiển thị hoặc phát lại. Mỗi hop có thể thêm độ trễ nên được nhìn thấy trong thiết kế.
Sau khi đường dẫn được lập bản đồ, tổng độ trễ cho phép có thể được chia thành các đoạn. Mạng truy cập có thể nhận một mục tiêu, mạng lõi mục tiêu khác, nền tảng ứng dụng mục tiêu khác và xử lý điểm cuối mục tiêu khác. Việc phân bổ phải thực tế. Một số phần có thể được tối ưu hóa mạnh mẽ, trong khi những phần khác có giới hạn vật lý hoặc kỹ thuật.
Xác minh toàn bộ đường dẫn trong điều kiện bình thường, bận rộn và phục hồi bằng cách sử dụng tải và cửa sổ quan sát được nêu rõ. Báo cáo phân phối độ trễ, mất mát, loại bỏ muộn, timeout và độ không đảm bảo đồng hồ. Phân vị của các đoạn nói chung không thể cộng lại để có được phân vị end-to-end; đo đường dẫn kết hợp và phân biệt giới hạn cứng với mục tiêu thống kê.
Sai lầm phổ biến trong thiết kế ngân sách độ trễ
Một sai lầm phổ biến là chỉ sử dụng độ trễ trung bình. Giá trị trung bình có thể che giấu các đợt tăng độ trễ ngắn làm hỏng dịch vụ thời gian thực. Các ứng dụng thoại, video và điều khiển thường chịu đựng độ trễ không ổn định nhiều hơn là độ trễ cao hơn một chút nhưng ổn định. Một ngân sách hữu ích nên xem xét jitter, độ trễ đỉnh và biến động độ trễ.
Một sai lầm khác là bỏ qua xử lý tại điểm cuối. Các kỹ sư có thể tập trung nhiều vào độ trễ mạng trong khi quên độ trễ codec, xử lý camera, hiển thị, mã hóa, hàng đợi ứng dụng hoặc phản hồi cơ sở dữ liệu. Trong nhiều hệ thống, mạng chỉ là một phần của chuỗi độ trễ.
Một số dự án cũng đặt mục tiêu mà không xem xét địa lý. Đường dẫn dài có độ trễ lan truyền không thể tránh khỏi. Nếu người dùng, máy chủ và dữ liệu được đặt cách xa nhau, ngân sách phải phản ánh thực tế đó. Yêu cầu độ trễ cực thấp từ kiến trúc đám mây từ xa có thể không thực tế.
Sai lầm cuối cùng là coi ngân sách độ trễ như một tài liệu thiết kế một lần. Lưu lượng mạng thay đổi, ứng dụng được cập nhật, nhiều người dùng hơn được thêm vào, điều kiện không dây thay đổi và chức năng nền tảng mở rộng. Ngân sách độ trễ nên được xem xét lại khi hệ thống thay đổi, đặc biệt khi các dịch vụ mới được thêm vào cùng một đường truyền thông.
Cách đánh giá liệu ngân sách độ trễ có thành công hay không
Ngân sách độ trễ thành công không được đánh giá bằng giấy tờ. Nó được đánh giá bằng việc hệ thống có cung cấp liên lạc ổn định trong điều kiện thực tế hay không. Tiêu chí đầu tiên là liệu độ trễ end-to-end có nằm trong yêu cầu dịch vụ hay không. Tiêu chí thứ hai là liệu mỗi đoạn có duy trì gần mục tiêu được phân bổ hay không. Tiêu chí thứ ba là liệu độ trễ có ổn định khi hệ thống bận rộn hay không.
Trải nghiệm người dùng cũng nên được xem xét. Một hệ thống thoại có thể vượt qua kiểm thử độ trễ về mặt kỹ thuật nhưng vẫn cảm thấy không tự nhiên nếu jitter cao. Một hệ thống video có thể hiển thị độ trễ trung bình chấp nhận được nhưng bị đóng băng khi tắc nghẽn. Một hệ thống điều khiển có thể đáp ứng thời gian bình thường nhưng thất bại trong lưu lượng cao điểm. Các phép đo và hành vi dịch vụ thực tế nên được xem xét cùng nhau.
Đội vận hành cũng nên có thể xác định độ trễ nhanh chóng. Nếu hiệu năng trở nên tồi tệ hơn, ngân sách sẽ giúp xác định liệu vấn đề nằm ở liên kết truy cập, WAN, máy chủ, ứng dụng, đoạn không dây hay điểm cuối. Giá trị chẩn đoán này là một trong những lý do mạnh mẽ nhất để tạo ngân sách độ trễ ngay từ đầu.
Khi ngân sách độ trễ được thiết kế tốt, nó trở thành tài liệu tham chiếu chung cho thiết kế, triển khai, nghiệm thu, bảo trì và mở rộng trong tương lai. Nó biến "độ trễ thấp" từ một yêu cầu mơ hồ thành một mục tiêu kỹ thuật có thể kiểm soát được.
Đọc kỹ thuật liên quan
Câu hỏi thường gặp
Ngân sách độ trễ truyền thông có giống với độ trễ mạng không?
Không. Độ trễ mạng là một phần của tổng độ trễ. Ngân sách độ trễ truyền thông bao gồm độ trễ mạng, xử lý tại điểm cuối, đệm, xử lý máy chủ, chuyển đổi giao thức, phản hồi ứng dụng và các nguồn độ trễ khác trên toàn bộ đường dịch vụ.
Ngân sách độ trễ có thể được sử dụng trong ứng dụng đám mây không?
Có. Ứng dụng đám mây thường đi qua nhiều lớp dịch vụ, khu vực, cổng, cơ sở dữ liệu và API. Ngân sách độ trễ giúp xác định mỗi lớp có thể tiêu hao bao nhiêu thời gian và liệu có cần xử lý biên, bộ nhớ đệm hoặc triển khai theo khu vực hay không.
Ngân sách độ trễ nên được xem xét lại bao lâu một lần?
Nên được xem xét lại khi các dịch vụ mới được thêm vào, quy mô người dùng thay đổi, đường dẫn mạng thay đổi, khu vực đám mây di chuyển, điều kiện không dây thay đổi hoặc các khiếu nại về hiệu năng thời gian thực tăng lên. Ngân sách độ trễ nên phát triển cùng với hệ thống.
