구글의 트루타임 API 복제가 어려운 이유는?

구글의 트루타임 API 복제가 어려운 이유는?

일반적으로 언론에서 Google의 TrueTime API를 복제하기 어렵다고 하는 이유(Wired, Slashdot 등)를 잘 모르겠습니다.

구글이 달성하고 있는 낮은 오류 간격을 얻는 것이 얼마나 어려운 일인지는 이해할 수 있지만, API 자체가 얼마나 어려운 일인지는 알 수 없습니다.

예를 들어, 해킹당한 버전을 같이 휘핑했습니다.여기 간격이 있습니다.

    typedef struct TT_interval {
            struct timeval earliest;
            struct timeval latest;
    } TT_interval;

지금 기능입니다.

    int TT_now(TT_interval* interval)
    {
        struct ntptimeval tv;
        struct timeval delta;

        struct timeval* earliest_p = &(interval->earliest);
        struct timeval* latest_p = &(interval->latest);
        struct timeval* now_p = &(tv.time);
        struct timeval* delta_p = δ

        timerclear(&delta);
        timerclear(&interval->earliest);
        timerclear(&interval->latest);

        if(ntp_gettime(&tv) == 0) {
            tv.maxerror = tv.maxerror > 0 ? tv.maxerror : -(tv.maxerror);

            delta.tv_sec = delta.tv_sec + (tv.maxerror / 1000);
            delta.tv_usec = delta.tv_usec + ((tv.maxerror % 1000) * 1000);

            if(delta.tv_usec > 1000000) {
                delta.tv_usec -= 1000000;
                delta.tv_sec++;
            }

            timeradd(now_p, delta_p, latest_p);
            timersub(now_p, delta_p, earliest_p);
        } else {
            printf("error on ntp_gettime. %s\n", strerror(errno));
            return ERROR;
        }

        return SUCCESS;
    }

마지막으로, 여기에 이전 및 이후 기능(지금 기능 주변의 포장지이며 약간의 DRY 리팩토링을 사용할 수 있음)이 있습니다.

    int TT_before(TT_interval* interval, bool* success)
    {
        struct timeval* latest_p;
        struct timeval* earliest_p;
        TT_interval now;

        if(TT_now(&now) != SUCCESS) {
            return ERROR;
        }

        latest_p = &(interval->latest);
        earliest_p = &(now.earliest);

        if(timercmp(latest_p, earliest_p, <) != 0) {
            *success = true;
            return SUCCESS;
        } else {
            *success = false;
            return SUCCESS;
        }

        return ERROR;
    }

   int TT_after(TT_interval* interval, bool* success)
    {
        struct timeval* latest_p;
        struct timeval* earliest_p;
        TT_interval now;

        if(TT_now(&now) != SUCCESS) {
            return ERROR;
        }

        earliest_p = &(interval->latest);
        latest_p = &(now.earliest);

        if(timercmp(latest_p, earliest_p, <) != 0) {
            *success = true;
            return SUCCESS;
        } else {
            *success = false;
            return SUCCESS;
        }

        return ERROR;
    }

약 5,000us에서 350,000us(공용 NTPd 사용)의 간격 오류가 발생하는 것 같습니다.이것은 구글의 숫자와는 거리가 멀지만, 어딘가에서 시작할 필요가 있습니다.

성능이 떨어지는 것 외에 이 디자인에 스패너와 같은 것이 위에 만들어지는 것을 방해하는 큰 결함이 있습니까?

TrueTime API를 구현할 때의 과제는 제공해야 하는 보장에 있습니다.즉, 절대 시간은 시스템의 어떤 서버에서도 TrueTime 간격을 벗어나지 않아야 합니다.이런 일이 발생할 수 있다면, 대부분의 Spanner 보증과 마찬가지로 이벤트의 절대적인 순서가 없어집니다.

Spanner paper는 다음과 같은 수단을 조합하여 이를 달성합니다(섹션 3).

1. 다른 데이터 센터의 타임 서버를 포함하여 서로 다른 소스(GPS, 원자 시계)를 가진 여러 타임 서버.
2. 거짓말쟁이를 탐지하고 신뢰할 수 있는 다양한 시간 소스를 로컬 기계 시계의 업데이트로 다중화하는 Marzulo의 알고리즘.
3. 스팬 서버에서 가정한 200us/s 클럭 드리프트로, 클럭 동기화 사이에 적용됩니다.
4. 측정된 로컬 클럭 드리프트 > 임계값(필요에 따라 임계값 << 200us/s)을 나타내는 시스템으로부터 킥 머신.

이제 NTP와 가정된 10분의 오차 간격으로 이를 달성할 수 있습니다.그러나 질문에서 언급한 바와 같이, 이에 대한 성과적 함의가 있습니다.읽기-쓰기 트랜잭션(4.2.1)은 커밋 시 대기해야 하며, 예상 대기 시간은 2*errorAverage - 이 예에서 20분입니다.마찬가지로 과거 시간이 아닌 "지금" 시간의 읽기 전용 트랜잭션(4.2.2)은 안전 시간이 충분히 진행될 때까지 기다려야 합니다(이 예에서는 최소 10분).따라서 고성능 시스템을 갖추기 위해서는 가능한 한 오차 간격을 최소화하고, 보장을 잃지 않아야 하며, 이는 복잡성이 발생하는 부분입니다.

시스템에서 ntp_adjtime이 어떻게 호출되고 있는지 잘 모르겠습니다. 신뢰할 수 없고 상관이 없는 여러 시간 소스를 사용하여 이미 설정되어 있을 수 있습니다. 이 경우에는 이미 거의 모든 방법을 사용하고 있습니다.또한 최대 오류 값이 시스템의 가능한 클럭 드리프트보다 더 빠르게 진행되도록 보장할 수 있다면 사용하는 것이 좋습니다.개인 원자 시계가 없는 스패너의 대부분의 성능 :).

언급URL : https://stackoverflow.com/questions/18384883/why-is-googles-truetime-api-hard-to-duplicate