MQL5 웹사이트에서 볼 수 있는 차트에서 100 PR 단위의 시간 비용을 인용할 것을 제안합니다. 사이트를 통해 프로세서 시간의 구매자와 판매자는 100 PR 단위 시간의 구매 및 판매에 대한 입찰을 제출합니다. 예를 들어 지난 120일(거의 1/4 분기) 동안의 모든 주문이 누적되고 균형 가격 PRice120이 계산됩니다. 이 균형 가격은 100 PR 단위의 시간당 비용이 됩니다. 프로세서 시간 판매자의 주문 가격이 PRice120 가격보다 낮으면 프로세서 시간이 판매되고 높으면 판매가 수행되지 않습니다. 구매자의 경우는 그 반대입니다.
주문 누적이 발생하는 기간은 30일, 60일 등의 여러 옵션 중에서 각 구매자와 판매자가 개별적으로 선택합니다. 트리거될 때 균형 가격에서 가격의 편차도 각 구매자와 판매자가 선택합니다.
제 생각에는 너무 어렵습니다. 가격은 통계 및 추가 정보를 기반으로 중앙에서 설정되어야 합니다. 개발자만 일반 통계를 보고 카드를 손에 들고 있습니다.
그리고 수요와 공급에 따라 주기적으로 가격(분기에 한 번)을 조정합니다. 그들이 가격을 1센트로 설정하고 필요 이상으로 클라우드와 함께 일할 의향이 있는 사람들이 훨씬 더 많을 것이라고 가정해 봅시다. 우리는 더 많은 사람들이 기꺼이 그들의 능력을 제공할 수 있도록 가격을 높여야 할 것입니다.
가격이 너무 높으면 구매자가 (사설 네트워크 또는 다른 곳을 통해) 떠나고 반대로 가격을 인하해야 합니다.
Mischek : TeamWox를 구매한 기업 고객이 있습니다. 아마도 회사의 누군가가 그들과 관계를 유지하고 있을 것입니다. 아마도 그들에게 "80-90%에서 여전히 유휴 상태인 컴퓨터 용량의 활용도/로딩을 증가시키는 아이디어"를 제공하려고 노력할 가치가 있을 것입니다. 그들은 이미 당신의 회사를 신뢰하고 있고 가격 문제는 신속하게 결정할 수 있습니다.아마도 그것은 공정하고 최적에 가까울 것입니다.
또 다른 아이디어가 있습니다. 우리는 다양한 분산 컴퓨팅 프로젝트(SETI@home 및 BOINC 플랫폼의 유사한 프로젝트)에 수십 년 동안(거의 항상 무료로) 참여해 온 거대한 매니아 커뮤니티를 끌어들이려고 노력할 것입니다.
적은 금액을 위해 손가락 하나 까딱(여기서는 전체 수동 거래)하고 싶어 하는 사람이 없기 때문에 이것은 너무 복잡한 계획입니다. 시스템은 자동 모드에 가깝게 작동해야 합니다.
나는 정확히 거래를 의미하지 않았습니다. CPU 시간 구매자는 N 시간 100 PR 단위를 구매하려고 합니다. 그는 어떻게 해서든 서버에 나 Ivan_Ivanov가 N개의 시계를 사고 싶고 그것에 대해 M 센트를 지불할 준비가 되었음을 알려야 합니다. 구매자는 구매를 위해 자신의 개인 계정에 주문을 하고, 그의 가격이 120일 동안의 일부 가격, 기본, 균형 이상이거나 다른 경우 구매자는 프로세서 시간을 구매합니다. 요점은 사이트를 통해 하는 CPU 시간 매수/매도 제안은 매수/매도를 위한 서버에 대한 명령이자 가격을 결정하기 위한 통계 데이터라는 것입니다. 그리고 가격 차트는 정보 제공을 위한 것입니다.
다음 범주의 사용자에 중점을 둡니다.
더욱이, 1년 안에 사용하지 않은 시간에 자원을 판매하기 위해 일정 기능을 사용하는 사용자의 세 번째 범주가 우세할 것이라는 느낌이 있습니다.
4. 3과 2인 사람들, 1이 필요할 때까지 - 1처럼 행동하는 경우는 훨씬 적습니다(MQL5를 스스로 마스터하는 거래자).
%는 물론 목소리를 내는 것이 어렵다고 생각합니다.
//////////////////////////////////
계산에 포함되어야 합니다.
예 : 나는 시간당 할머니에게 공짜로 돈을 모으지 않기 위해 며칠 동안 무화과를 흔들었다.
질문: "느림"(예: 지연(ping)으로 인해)이 어떻게든 차단됩니까? 또는 주문/실적에 대한 작업을 입력하려면?
//////////////////////////////////
반대편에. 대부분의 사용자는 개발자 서버의 용량을 가지고 있지 않으며, 이 서버에서 가장 먼저 계산이 수행됩니다.
코어 판매자에게 남은 것은 무엇입니까?
//////////////////////////////////
솔직히 말해서, 무엇을 계산해야 하는지에 따라 아직 적절한 수치가 보이지 않습니다.
한편으로는 최소한 클라우드 비용을 알고 MetaQuotes(가장 낮은 가격표)에 대한 기업의 수익성에서 시작해야 합니다. 잠재적인 판매자 및/또는 구매자로서 나는 핵심에서 하루 1달러에 만족한다고 가정해 보겠습니다. 개발자들은 10센트에 만족할까요?
사용자의 입장에서 회사의 비용으로 ... 잘 xs. 이 스레드에서도 $500와 $2000이 발표되었습니다. 큰 확산.
아마도 구매자가 지불할 의사가 있는 금액과 이러한 구매자가 몇 명인지부터 계속 진행해야 할 필요가 있습니다.
일반적으로 어드바이저의 평균 가격(복잡도에 따라 다름)을 시작으로 생각하는 것은 어리석은 일입니다. 주문 작업을 하는 프로그래머가 알아낼 수 있을까요? 그런 다음 계수를 조정합니다. 클라우드의 총 부하에서 옵션으로.
MQL5 웹사이트에서 볼 수 있는 차트에서 100 PR 단위의 시간 비용을 인용할 것을 제안합니다. 사이트를 통해 프로세서 시간의 구매자와 판매자는 100 PR 단위 시간의 구매 및 판매에 대한 입찰을 제출합니다. 예를 들어 지난 120일(거의 1/4 분기) 동안의 모든 주문이 누적되고 균형 가격 PRice120이 계산됩니다. 이 균형 가격은 100 PR 단위의 시간당 비용이 됩니다. 프로세서 시간 판매자의 주문 가격이 PRice120 가격보다 낮으면 프로세서 시간이 판매되고 높으면 판매가 수행되지 않습니다. 구매자의 경우는 그 반대입니다.
주문 누적이 발생하는 기간은 30일, 60일 등의 여러 옵션 중에서 각 구매자와 판매자가 개별적으로 선택합니다. 트리거될 때 균형 가격에서 가격의 편차도 각 구매자와 판매자가 선택합니다.
제 생각에는 너무 어렵습니다. 가격은 통계 및 추가 정보를 기반으로 중앙에서 설정되어야 합니다. 개발자만 일반 통계를 보고 카드를 손에 들고 있습니다.
그리고 수요와 공급에 따라 주기적으로 가격(분기에 한 번)을 조정합니다. 그들이 가격을 1센트로 설정하고 필요 이상으로 클라우드와 함께 일할 의향이 있는 사람들이 훨씬 더 많을 것이라고 가정해 봅시다. 우리는 더 많은 사람들이 기꺼이 그들의 능력을 제공할 수 있도록 가격을 높여야 할 것입니다.
가격이 너무 높으면 구매자가 (사설 네트워크 또는 다른 곳을 통해) 떠나고 반대로 가격을 인하해야 합니다.
유일한 질문은 어떤 가격을 기준으로 삼을 것인가입니다.
TeamWox를 구매한 기업 고객이 있습니다. 아마도 회사의 누군가가 그들과 관계를 유지하고 있을 것입니다. 아마도 그들에게 "80-90%에서 여전히 유휴 상태인 컴퓨터 용량의 활용도/로딩을 증가시키는 아이디어"를 제공하려고 노력할 가치가 있을 것입니다. 그들은 이미 당신의 회사를 신뢰하고 있고 가격 문제는 신속하게 결정할 수 있습니다.아마도 그것은 공정하고 최적에 가까울 것입니다.
또 다른 아이디어가 있습니다. 우리는 다양한 분산 컴퓨팅 프로젝트(SETI@home 및 BOINC 플랫폼의 유사한 프로젝트)에 수십 년 동안(거의 항상 무료로) 참여해 온 거대한 매니아 커뮤니티를 끌어들이려고 노력할 것입니다.
우리는 좋은 인센티브가 있습니다 - 자원에 대한 지불.
Renat :
MetaQuotes-Demo 서버에 여러 합성 도구를 설정하여 판매자, 구매자 및 가격의 수를 모니터링할 수 있습니다. 가격 계산/수정 공식은 모든 것을 투명하게 만들기 위해 공개적으로 사용할 수 있습니다.
기본 가격을 명시적으로 변경하거나 계산 공식을 조정해야 하는 경우 공개 토론을 통해 이를 수행할 수 있습니다.
또 다른 아이디어가 있습니다. 다양한 분산 컴퓨팅 프로젝트( SETI@home 및 BOINC 플랫폼의 유사한 프로젝트)에 수십 년 동안(거의 항상 무료로) 참여해 온 거대한 매니아 커뮤니티를 끌어들이려고 노력할 것입니다.
질문: "느림"(예: 지연(ping)으로 인해)이 어떻게든 차단됩니까? 또는 주문/실적에 대한 작업을 입력하려면?
클라우드 서버에서 결정되고 그에 따라 "성능 및 시간"이 조정됩니다. 이것은 주로 부정 행위를 방지하기 위한 것입니다.
코어 판매자에게 남은 것은 무엇입니까?
우리는 자원을 판매할 계획이 없으며 전 세계에 거대한 유통 네트워크를 구축하는 것이 목표입니다.
물론 최소한 초기 단계에서는 리소스의 일부를 무료로 배포할 것입니다.
우리는 분산 네트워크의 운영자일 뿐이며, 목표는 수만 및 수십만 명의 결제 에이전트를 위한 클라우드를 만드는 것입니다.
지리적으로 분산된 클라우드 서버 목록을 살펴보십시오. 부하가 증가할수록 더 많아질 것입니다.
간단한 변형은 1 Unit Price = Base Price * Func( Sellers, Buyers, Time) 형식으로 제안됩니다.
그 결과, 가격은 수급에 따라 매시간 자동으로 조정됩니다.
그리고 기존 클라우드 서비스의 기본 '평균 병원비'를 들 수 있습니다.
네, 저도 그런 생각을 했습니다. 그러나 가격에는 디스크, 메모리 및 CPU가 포함된 전체 컴퓨터와 나머지 보안 인프라 및 백업이 포함됩니다.
적은 금액을 위해 손가락 하나 까딱(여기서는 전체 수동 거래)하고 싶어 하는 사람이 없기 때문에 이것은 너무 복잡한 계획입니다. 시스템은 자동 모드에 가깝게 작동해야 합니다.